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I. INTRODUCTI ON 

A. DISCUSSION 

1 . General 

The goal of this thesis is to extend the existing 
version of the distributed multi- computer real time 
executive (E-MCORTEX) in order to provide systemwide 
interprocess data communication. 

The existing MCORTEX version was provided by David 
Brewer in December 1984 [Ref. 1], and contributes to the 
research work done by the AEGIS Modeling Group at the Naval 
Postgraduate School (NPS). 

The objective of this project group is research on 
time critical processing required by modern anti-air warfare 
(AAW) systems. The project group chose the AN/SPY-1A phased 
array radar processing unit of the AEGIS weapon system due 
to its challenging time critical processing demands. A 
further fundamental objective of the AEGIS Modeling Group is 
to use off the shelf components within the AEGIS weapons 
system as a low cost approach, and to upgrade reliability of 
the system by replacing the AN/UYK-7 central computer of the 
AN/SPY-1A system by distributed computing power. Rapid 
repair turnaround and low component replacement cost in the 
system in case of failure, and graceful degradation of the 
system are of utmost importance especially for military 
applications . 

The available lab system at NPS is made up of single 
board computers building MULTIBUS clusters which are 
connected via an Ethernet Local Area Network. 

2 . Systems Architecture 

The lab system's hardware configuration shown in 
Figure 1.1 consists of two clusters with up to four Intel 
iSBC 86/12A single board computers (SBC) in a cluster at the 
present time. A MULTIBUS serves as the interconnection 
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Figure 1.1 Hardware Configuration of RTC*. 



12 



medium for all cluster elements, i.e. besides the SBC ' s , a 
hard disk drive, two extra memory boards, and an interLAN 
NI3010 Ethernet Communication Controller Board (ECCB) . The 
ECCB provides, via a transceiver, the cluster’s connection 
to the Ethernet . 

With the MULTIBUS as an intracluster bus and the 
Ethernet as an intercluster bus the system's configuration 
looks similar to Carnegie Mellon's Cm* [Ref. 2]. Due to its 
goal to serve time critical applications in a real time 
environment the AEGIS lab system is known as Real-Time 
Cluster Star (RTC*) . 

The system's software configuration shown in Figure 
1.2 consists of a MCORTEX kernel on every SBC, MCORTEX 
global data on one extra memory board, known as Common 
Memory, and Shared Memory on the second extra memory board 
in every cluster. Besides the MCORTEX kernel, also the 
CP/M-86 operating system and DDT-86 are available in local 
RAM of every SBC, and the user area provides space for 
application programs. The CP/M Multiuser area is kept on the 
Common Memory board, while Shared Memory houses user shared 
data and some system's shared data. 

SBC 1 in every cluster is dedicated to a systems 
program known as the system device handler and packet 
processor (called a driver in the following). Part of 
Shared Memory is used as a data exchange buffer between any 
SBC in the cluster and the driver board, SBC 1, for Ethernet 
transmission requests. Another part serves as data exchange 
buffer between the driver board and the ECCB for handing 
over messages which are to be transmitted and messages which 
have been received. 

The distributed MCORTEX kernels provide the 
multiprocessing capability of the system. System processes 
and user processes share the CPU of a respective SBC. David 
Brewer gives an in depth discussion of the interrelationship 
and the scheduling of processes. 
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The process synchronization is accomplished using 
eventcounts and sequencers as developed by Reed and Kanodia 
[Ref. 3]. Eventcounts synchronize all processes, those 
running on the same board as well as those running on 
different boards in the same cluster as well as those 
running on boards in different clusters. 

It is important to recognize that eventcounts are 
also data, even though a special kind of data. 

3 . Specific 

A typical application situation for systems like 
RTC* is time critical gathering of data by real time sensors 
(e.g. radar), processing these data in the context of 
information gathered by other sensors, and executing 
specific algorithms in order to produce data that are 
consumed by effectors (e.g. missile launchers). 

Under the realistic assumption that sensors and 
effectors are locally distributed and that sensor- effector 
coupling or grouping must be kept flexible for the sake of 
weapon system survivability, it is obvious that the 
different processing modules cannot be kept together close 
enough in order to use shared memory in the conventional 
sense . 

B . BACKGROUND 

A series of theses starting with one by W.J Wasson, June 

1980, which defined the detailed design of MCORTEX based on 
MULTICS and the use of eventcounts [Ref. 4], developed a 
highly modular system, hardwarewise and sof twarewise , using 
commercially available components, that guarantee low cost, 
availability, and reliability. D . K . Rapantzikos , March 1981, 
provided initial implementation [Ref. 5], E.R. Cox, December 

1981, refinement [Ref. 6], and S.G. Klinefelter, June 1982, 
dynamical interaction with the operating system during 
execution [Ref. 7]. 

W.R. Rowe, June 1984, put the multiuser CP/M-86 
operating system under control of MCORTEX [Ref. 8], and 
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finally D.J. Brewer, December 1984, extended MCORTEX to a 
multicluster system without shared memory, using Ethernet as 
cluster interface. 

The system’s functioning was shown for the extended 
MCORTEX version up to the level of systemwide process 
synchronization using distributed eventcounts in a 
multicluster environment. Even though eventcounts are data 
also, and communicating eventcounts is shared data 
communication, this special shared data communication lacks 
the ability of user shared data distribution over the total 
system. 

This thesis tackles this important step. 

C. STRUCTURE OF THE THESIS 
The goals of this thesis are: 

1. To extend the existing MCORTEX version, that provides 
process synchronization and single cluster 
inter-systemprocess data communication using an intracluster 
shared memory, to multicluster general inter-process data 
communication in an Ethernet Local Area Network environment. 

2. To develop' an appropriate model for intercluster 
shared memory to be used in the system. 

3. To accomplish the extension without changing the 
MCORTEX kernel, but modifying PL/I-86 modules only. 

Chapter I discusses the objective of the AEGIS Modeling 
Group at the Naval Postgraduate School, gives an 
introductory system's overview, a brief development history 
of the system, and outlines the goals of this thesis. 

Chapter II discusses three different approaches studied 
in developing the concept of intercluster shared memory for 
RTC*, and the reasoning that lead to the decision for the 
chosen model. 

Chapter III presents the organization of intracluster 
shared memory, the use of the user shared data area, and the 
intracluster data flow. 
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Chapter IV provides an in depth presentation of the 
development and realization of intercluster data sharing in 
RTC* . 

Chapter V summarizes the current state of the system 
and addresses possible future enhancements. 
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II. ORGANIZATION OF INTERCLUSTER SHARED MEMORY 



A. SHARED MEMORY MODELS 

In developing the concept of intercluster shared memory 
for RTC*, three different approaches were studied: 

1) no replication of intracluster shared memory, 

2) total replication of intracluster shared memory, and 

3) partial replication of intracluster shared memory. 

The logical structures of these approaches are shown in 
Figure 2.1. 

1. No Replication 

This model views the intercluster shared memory as 
the sum of individual intracluster shared memories of all 
clusters available in the system. This is very similar to 
the approach chosen for Cm*. 

Every shared data item is kept only once in 
intercluster shared memory, normally in the intracluster 
shared memory of the home cluster of the producing process. 
Consuming processes have to go through the various bus 
hierarchies of the system in order to access the respective 
item at the time when consumption is to start. Apparently 
this is a very time consuming effort if the respective data 
item is not resident close to the consuming process. Close 
in this context refers to being located in shared memory of 
the consuming process' home cluster. In terms of time 
efficiency for this model, the only reasonable solution for 
this situation is to put producing and consuming processes 
as close together as possible in order to increase the rate 
of cluster local hits. 

The space-time dilemma becomes obvious. In terms of 
space, this approach is the most efficient one, because 
there exist no duplications of any data item in the whole 
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system. The intercluster shared memory space is equal to the 
sum of all intracluster shared memory spaces in the system. 

However, if we accept the fact that memory becomes 
cheaper and cheaper every year due to development of 
technologies that put more and more memory space on a chip, 
then we could afford to replicate data in different memories 
of the system in order to increase the number of cluster 
local hits, or even to ensure that only local hits happen in 
the system. This leads to the second model of intercluster 
shared memory. 

2 . Total Replication 

The opposite extreme of no replication is total 
replication of all shared memory, i.e. every intracluster 
shared memory keeps all shared data items and so 
intercluster shared memory consists of as many copies of 
intracluster shared memory as there are clusters in the 
system. Due to the necessity that all intercluster shared 
memory has to fit in every intracluster shared memory, the 
available space for intercluster shared memory is equal to 
the space of the smallest intracluster shared memory of any 
cluster in the system. Therefore it must be ensured that the 
smallest intracluster shared memory is large enough to keep 
all shared data items needed in the system. 

This model makes sure that only cluster local hits 
occur in the system, and that every consuming process finds 
every data item in shared memory of its home cluster. This 
seems to be a very time efficient approach that suits the 
demand of having data as close as possible to the producer 
and the consumer as well. 

A major problem with this approach however is the 
increased overhead in maintaining and updating of shared 
data items that are never used at a certain cluster. This 
overhead especially consists of traffic on the systems buses 
and processing time of the hosts at the interfaces between 
clusters and transmission medium. This traffic overhead 
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slows down the data distribution so that it takes longer for 
data to be available at the consuming process' cluster for a 
local hit there . 

The compromise is a combination of these first two 
models, where only necessary replication of data is done. 

3 . Partial Replication 

In this model every cluster maintains shared data 
only if those data are used at a specific cluster, i . e . the 
producing and the consuming clusters only keep a copy of 
respective data items, no superfluous information is 
maintained and there is no superfluous traffic on the 
transmission medium and the system buses. The intercluster 
shared memory in this approach is equal to the union of all 
individual intracluster shared memories in the system and 
only the intersections are replicated. There can be 
different intersections between different cluster groups in 
the system. This approach is the most efficient one in 
terms of space and time. The traffic on the transmission 
medium and the system buses, and the amount of processing 
time needed for data exchange is kept to a minimum. Also, as 
in the total replication approach, only cluster local hits 
will occur. 

The overall policy is to transmit shared data to 
all consuming clusters as soon as possible after production, 
and to transmit those data to consuming clusters only. 

This approach seems to be the most adequate one for 
a distributed real time system, as it reflects the optimal 
compromise in terms of speed , space, and update overhead. 

Intercluster shared memory by partial replication of 
intracluster shared memories was therefore chosen for 
implementation in RTC*. 
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III. ORGANIZATION OF INTRACLUSTER SHARED MEMORY 



A. CLASSES OF SHARED DATA 

Looking closer at shared data, we realize that there are 
different classes of shared data used in the system. Some 
data is shared among processes on the same board only, some 
is shared among processes on different boards in the same 
cluster, and some is shared among processes in different 
clusters . 

It was decided to keep all shared data on special memory 
boards, even though some of the data is produced and 
consumed on the same board. To protect system's data used by 
the operating system, these data items are stored in Common 
Memory, which is beyond the reach of user data memory, 
called Shared Memory. 

All MCORTEX global data are maintained in Common Memory. 
Every cluster has one Common Memory where all MCORTEX global 
data needed in the respective cluster is kept. Brewer 
describes the logical organization of Common Memories. Due 
to the fact that eventcounts are used for intracluster and 
intercluster process synchronization, some of these 
eventcounts are replicated in more than one cluster. 

It must be recognized that there exist system's 
eventcounts in every cluster, e.g. ERB_READ and ERB_WRITE . 
These are used strictly cluster internally and do not belong 
to the intersection of intercluster Common Memory. These 
system event count have the same name in every cluster, but 
their respective values are never distributed over the 
system. Only user eventcounts that are used in more than one 
cluster are distributed and therefore replicated in 
respective clusters. 
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B. SYSTEM SHARED DATA 



A similar situation exists in Shared Memory. There are 
three data items in Shared Memory which are used exclusively 
within the cluster: 

1) the Ethernet_Request_Block , 

2) the Transmit_Data_Block , and 

3) the Receive_Data_Block. 

These are data items shared between the driver residing 
on SBC 1 and either MCORTEX kernels on other boards or the 
ECCB. These system's data items are needed to establish 
cluster external communication. Information needed by the 
driver about outgoing and incoming messages has to be 
communicated via Shared Memory, because it is not possible 
to access local memory of any SBC from outside the board. 

As is true for system eventcounts in Common Memory, 
these three system shared data items are also used strictly 
cluster internally and do not belong to the intersection of 
intercluster Shared Memory, even though they have the same 
names in every cluster. Only user shared data, that are 
shared in more than one cluster are distributed and 
therefore replicated at respective clusters. 

As described by Brewer, the Ethernet Request Block, the 
Transmit Data Block, and the Receive Data Block reside in 
this order in the lower part of Shared Memory at addresses 
10000H, 10078H, and 10666H respectively. The User Shared 
Data Block starts at address 10C58H and goes up to 17FFFH as 
the highest address in Shared Memory in the present 
implementation of RTC*. 

C. USER SHARED DATA 

Shared data items are basically interfaces between 
different processes. Processes communicate via these shared 
data. It is therefore important to agree on the name, size, 
and structure of shared data used by different programmers 
for different process modules. This agreement must be 
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accepted by all programmers of any system module and can be 
thought of as reached under the guidance of a lead 
programmer . 

An individual programmer can still use any other private 
name and structure for some variable, as long as he or she 
ensures that communication with any other module is done 
using the agreed upon name and structure. 

1. Organization of Shared Data 

Shared data items are organized as circular queues 
of structures, where the actual item is a structure and the 
queue serves as buffer between producers and consumers. This 
is true for user shared data and system shared data as well. 

While system shared data items have fixed predefined 
structures and queue lengths, a user shared data item can be 
of any structure, and a user shared data queue can be of any 
length. The only restriction is that all user shared data 
queues needed at some cluster must fit together into the 
User Shared Data Block in Shared Memory of that cluster. 

The length of specific data queues is another 
important issue to be agreed upon by all programmers using 
respective shared data items. The chosen queue length 
depends on the expected average input and output rate of a 
specific data item queue. The goal is to reduce or, if 
possible, to avoid idle waiting times at producing processes 
due to a filled up queue caused by slow consumption. 

As mentioned in Chapter II, the data communicating 
version of RTC* developed in this thesis will use the 
concept of partial replication of Shared Memory. Therefore 
we think of intercluster Shared Memory as the union of all 
intracluster shared memory blocks that contain user shared 
data. Data communication is only possible among clusters 
that actually share data (i.e. there exist an intersection 
of intracluster Shared Memories of those clusters and the 
respective shared data item is in the intersection). To put 
it another way, an intersection of intracluster Shared 
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Memories is only needed if processes in respective clusters 
need to communicate. If intracluster Shared Memories only 
keep those shared data items needed (produced or consumed) 
by some process in the cluster, then automatically the 
minimum intersection and therefore the least duplicated use 
of memory space and the most efficient use of time for 
maintaining the data is guaranteed. 

2. Storage of User Shared Data 

In order to further accomplish efficient use of 
memory space, the system is set up in such a way, that user 
shared data queues can be stored at any address in the User 
Shared Data Block in Shared Memory. There must, however, be 
enough space available between the starting address of the 
queue and the highest possible physical memory address 
(i.e.l7FFFH in the present implementation). 

This flexibility also allows for contiguous storage 
of all user shared data and thus the available storage space 
is most efficiently used. 

The same data item can reside under different 
addresses in different clusters. The application programmers 
do not have to worry about the addresses, they refer to a 
specific data item by its name. The lead programmer will 
take care of assigning addresses to shared data queues. When 
and how this is done will be discussed in Chapter IV. For 
now it should suffice to realize that the organization and 
storage of user shared data in this implementation is done 
with the least duplication of data items, where each shared 
data is available in the local cluster. 

D. RELATION BETWEEN SHARED DATA 

An important relation exists between system shared data, 
eventcounts and user shared data, which is exploited by the 
driver for its data communication task. 

The system internal management of a data queue is 
controlled using an eventcount <dataname>_IN and an 
event count <dataname> OUT. These eventcounts have to be 



25 



distributed over the same clusters as the related data item, 
in order to ensure that a consumer does not read a data item 
before it is in the queue, and a producer does not write a 
new item into an already used slot before the old item has 
been consumed by all its consumers. The eventcount 
<dataname>_IN tells all consumers that an item is available, 
the eventcount <dataname>_OUT tells the producer that a 
former used slot is available for new data. 

1. The Ethernet Request Block 

Refer to Figure 3.1 for the following discussion. 
The system shared data queue, the Ethernet Request Block 
(ERB) is filled with Ethernet Request Packets (ERP) 
initiated by any process resident at the cluster when it 
calls for an update of the value of an eventcount that is 
also needed at some other cluster. 

The many producers of Ethernet Request Packets are 
kept in sequence by the systems sequencer ERB_WRITE_REQUEST , 
which basically is a ticket machine that makes sure that 
only one packet at a time is put into the Ethernet Request 
Block, and that Ethernet Request Packets are put in on a 
first come first serve basis. The only consumer of Ethernet 
Request Packets is the driver on SBC 1. 

An Ethernet Request Packet keeps the following 
information in its eight byte structure: 

command (i.e. 00H means eventcount) 

type_name (i.e. 8 bit eventcount id) 
name_value (i.e. 16 bit eventcount value) 
remote_addr (i.e. 16 bit addr of external cluster) 

System event counts ERB_WRITE and ERB_READ play the 
functional roles of <dataname>_IN and <dataname>_OUT 
respectively for this system shared data queue. 

We realize that ERPs in the ERB are in partial 
order. The order of packets for different eventcounts 
<dataname>_IN or <dataname>_OUT is of minor importance. More 
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Figure 3.1 The Ethernet Request Block. 
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important to notice is that the logic of eventcounts, if 
used correctly, ensures 

a) that a packet with an event count <dataname>_OUT always 
comes after a packet with the respective eventcount 
<dataname>_IN, and 

b) that all packets with eventcounts <dat aname>_IN for a 
specific data queue are in total order, which is also true 
for all packets with eventcounts <dataname>_OUT for a 
specific data queue. 

2. User Shared Data Block 

As mentioned above, user shared data queues can be 
of any length and the data items can be of any structure, 
but every data item has a specific structure that is 
replicated in every slot of its data queue. 

Due to the information contained in the eventcount 
value, a specific slot in a data queue has to be written 
before the eventcount is advanced and also the eventcount 
has to have been advanced before the next slot is written 
to. The application programmer has to be aware of this 
logical sequence when using eventcounts. The system then 
ensures that always the next higher slot in the queue is 
written to, and this only if this slot is available for 
overwrite . 

This scheme also ensures that the data items in a 
respective queue are totally ordered. Furthermore, it is 
ensured that respective Ethernet Request Packets that keep 
value information of an eventcount related to this data item 
are in the same order as the data item iterations in the 
data queue. This is also true if an eventcount relates to 
multiple data. 

These facts about the relation between eventcounts, 
Ethernet Request Packets, and user shared data is the basis 
for the logic of the implementation of the drivers data 
transmission and data reception tasks. 
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Figure 3.2 User Shared Data Queues. 
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E. INTRACLUSTER DATA FLOW 



As mentioned earlier, we assume to have the classical 
producer- consumer situation for all user shared data in the 
system. Data items are kept in circular data queues that 
serve as buffers between producers and consumers. Due to 
this assumption, all user shared data are related to some 
event count, which replaces the semaphore used in the 
classical example. Refer to Figure 3.3 for the following 
discussion. 

A user process resides in the user area of local RAM on 
some SBC. The process becomes active when the scheduler 
chooses it as the next process to run after it was ready. 
Before a producer process can place the produced data item 
into the queue, a slot must be available. Slot availability 
can be checked by comparing the <dataname>_IN and the 
<dataname>_OUT eventcount values of the respective data 
queue . 

A consumer process becomes ready only when the value of 
the respective <dataname>_IN eventcount has reached the 
awaited threshold, indicating that there is a new iteration 
of the data item available in the data queue. 

A process which consumes data and produces new data as 
well obeys the same rules. It is of utmost importance that 
the application programmers use eventcounts and the AWAIT 
and ADVANCE primitives correctly. 

A producer process when running produces shared data 
items, puts these items into user shared memory, if there is 
space in the queue, and then calls the system primitive 
ADVANCE (EVC). This system process then increments the value 
of the respective eventcount and checks if this eventcount 
is distributed and therefore a cluster external copy needs 
to be updated. If so, it calls another system primitive, 
SYSTEM$IO, which in turn gets a ticket from the 
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Figure 3.3 Intracluster Data Flow. 
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ERB_WRITE_REQUEST sequencer and puts an Ethernet Request 
Packet into the Ethernet Request Block when its ticket 
number becomes the lowest in the waiting line. 

If no remote copy is needed, then no Ethernet Request 
Packet is produced, because all consumers reside in the same 
cluster as the producer, and the cluster internal 
synchronization can take place, as all needed data (i.e. 
eventcount value and shared data, if any) is present at the 
cluster. A waiting consumer process becomes ready and when 
activated consumes the shared data item from Shared Memory. 
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IV. INTERCLUSTER DATA SHARING IN RTC* 



A. INTERCLUSTER CONNECTION 
1 . The Ethernet 

As mentioned in the system overview in Chapter I, 
all clusters in RTC* are connected via an Ethernet Local 
Area Network. A detailed specification of the Ethernet is 
given by Xerox Corporation [Ref. 9]. The Ethernet provides 
the lowest two levels in the International Standards 
Organization's Open System Interconnection (ISO OSI) 
reference model, i.e. the Physical Layer and the Data Link 
Layer. Higher levels are collectively seen by the Ethernet 
as the Client Layer. The RTC*'s driver provides the 
system's Client Layer and the home board of the driver, SBC 
1, serves as a host in the Ethernet's communication subnet. 
The physical connection of a cluster to the Ethernet's 
coaxial cable is provided via the ECCB NI3010, the interface 
between the MULTIBUS and the transceiver which actually is 
the tap clamped on the coaxial cable. 

While the interface board provides the hardware 
connection between the highest level system bus (Ethernet) 
and the cluster bus (MULTIBUS), the ECCB software and the 
driver are responsible for correct exchange of messages 
transmitted or received by any cluster in RTC*. 

As is true for all SBCs , also communication with the 
ECCB NI3010 has to be done via board external buffers. In 
contrast to inter-SBC communication, which is synchronized 
by event counts, intercommunication between SBC 1, the 
driver's home board, and the ECCB is synchronized using 
interrupts (e.g. Transmit_DMA_Done or Receive_DMA_Done ) . 

An in depth description of the hardware NI3010 is 
given by InterLAN Corporation [Ref. 10]. The software 
driver was developed by David Brewer. Brewer's thesis 
provided the basic scheme for intercluster exchange of 
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eventcount values. The contribution of this thesis is to 
enhance the basic scheme for a general data exchange in the 
system by modifying the driver software and exploiting the 
logical interrelation between eventcounts and shared data. 

2. The Ethernet Packet 

Figure 4.1 shows the frame format of an Ethernet 
packet. This is a given structure produced by the ECCB. 
Information to be put into four of the six fields have to be 
provided by the client . Preamble and Frame Check Sequence 
are added by the ECCB for receiver synchronization and error 
checking respectively. 

For a destination address, any six byte combination 
except all zeroes can be used, which is also true for the 
source address. The arrows on the right hand side and the 
bottom of Figure 4.1 indicate the serial transmission 
sequence of the bytes and bits. The very first bit 
transmitted in the destination field indicates whether the 
destination address is a multicast or a physical address. If 
this bit is 1, making the first byte of the destination an 
odd number, then this address is a multicast address (group 
address of any number of clusters). A special multicast 
address, all ones, is reserved as the so-called broadcast 
address, which addresses all participants in the network. 

If the first bit is 0 then the destination is a 
physical address. Physical addresses are fixed addresses of 
ECCBs . Xerox Corporation takes care that physical addresses 
are unique, i.e. every physical address is used only once in 
any ECCB worldwide. 

Due to the just described restrictions, there are 
actually 2**47 different combinations available to be chosen 
as non-physical, non-broadcast destination addresses. For 
the present implementation of RTC* it was decided that two 
bytes are more than adequate, because the maximum number of 
stations for an Ethernet Local Area Network is restricted to 
1024 by the Ethernet specification. Therefore the first 
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Figure 4.1 The Ethernet Packet. 
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four bytes of the destination are kept fixed 03H, 00H, 00H, 
00H providing the multicast indication by an odd first byte. 

For the the source address, the ECCB allows two 
possible ways. Either this address is not provided by the 
client, in this case the ECCB automatically inserts its 
physical address, or the client fills in a source address. 
This second way speeds up the transmission process and was 
therefore chosen for RTC*. The first four bytes are kept 
fixed 03H, 00H, 00H, 00H as in the destination field. Byte 
five and six contain the cluster's address. This is not the 
ECCB's physical address as mentioned by David Brewer, but 
rather a software address of the transmitting cluster. 

The two bytes of the type field are reserved for 
use by higher levels. Clients can use this field in order to 
exchange information about a specific format used in the 
data field. The present implementation of RTC* will not use 
the type field and therefore sets it to 00H, 00H. 

The data field provides space for up to 1500 bytes. 
It is required that the minimum length of the data field be 
46 bytes in order to generate the minimum total length of a 
sufficiently long message. This minimum message size 
requirement guarantees that in any Ethernet collisions are 
detected by the sending stations, even if source and 
destination stations are maximum distance (2.5 km) apart, 
and the net performs at worst case propagation speed 
tolerated by the Ethernet specification. Collision detection 
by the sending station is important for correct backoff and 
retry in order not to loose messages in the network. The 
ECCB takes care of this minimum length requirement as will 
be seen later. Also the sending ECCB attaches a four byte 
frame check sequence at the end of every Ethernet packet in 
order to provide a basis for error checking to the receiving 
ECCB. 
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B. DRIVER - ECCB MESSAGE HANDOVER 

By a chosen wiring option, it is not possible to access 
(write or read) onboard memory of an SBC or the ECCB from 
outside the board. Therefore a buffer for message handover 
is needed for outgoing messages as well as for incoming 
ones. These buffers are set up in Shared Memory as systems 
shared data Transmit Data Block and Receive Data Block. In 
contrast to other shared data (e.g. Ethernet Request Block 
or user shared data), the Transmit Data Block and the 
Receive Data Block are single slot queues that meet the 
structure requirements given by the ECCB specification 
described in the Ethernet Communication Controller User 
Manual . 

1 . Transmit Data B lock 

The Transmit Data block is a structure of 1514 bytes 
that contains all information required to be submitted by 
the client in order to enable the ECCB to build the Ethernet 
packet described above. Figure 4.2 shows this structure. The 
destination and source fields are filled with the preset 
address parts as well as the dynamically changing two high 
bytes of the destination. The type field keeps the values 
00H, 00H, and the actual message content is kept in the 
lower part of the 1500 bytes data field. 

2 . Receive Data Block 

The Receive Data Block, see Figure 4.2, is similar 
to the Transmit Data Block and carries all information 
contained in an incoming message, i.e. destination, source, 
type and data field. In addition, the receiving ECCB hands 
over status information related to the message, that can be 
used by the client in order to determine the length and the 
error status of the received packet. These additional items 
of information are kept in the first four bytes (1 byte 
frame status, 1 null byte, 2 bytes frame length) and the 
last four bytes (frame check sequence) of the Receive Data 
Block, making the Receive Data Block 1522 bytes long. 
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The present implementation of RTC* ignores the 
frame check sequence and concerns itself only with the data 
field . 

Even though the length of the data field in the 
Ethernet packet is determined by the length of the actual 
message, both, the Transmit Data Block and the Receive Data 
Block provide space for maximum length messages in order to 
be prepared for any legal message size. 

C. MESSAGE TRANSMISSION AND RECEPTION 

The main task of the driver on SBC 1 is to build a 
message that is to be transmitted over the Ethernet, and to 
process a message that was received. For transmission, the 
message has to be built in the Transmit Data Block in Shared 
Memory first, and then the ECCB is to be triggered for 
transmission. For reception, after the ECCB signaled that 
it has put a message into the Receive Data Block in Shared 
Memory, the correct data queues in Shared Memory have to be 
found and the data items have to be put into the correct 
slots in their respective data queues. 

In order to be able to do this correctly, every driver 
maintains a table in its local RAM which contains all the 
information needed about the relationship between 
event counts and shared data items. 

1 . The Relation Table 

We assume that every user shared data item used in 
the system is related to some eventcount. The driver 
exploits <dataname>_IN eventcount, because this is the 
trigger for shared data transmission when put into an 
Ethernet Request Packet by the SYSTEM$IO process. 

Only if a <dataname>_IN eventcount was advanced, was 
there a new data item put into the respective data queue. An 
eventcount can also serve as a <dataname>_IN indicator for 
multiple data items that are updated at the same time. The 
important property is that for every shared data item there 
exist one <dataname>_IN eventcount, which is advanced after 
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the data item is available in its corresponding data queue 
in Shared Memory. Only if an eventcount is distributed over 
the system, and therefore a cluster external copy is needed, 
is there an Ethernet Request Packet produced- and put into 
the Ethernet Request Block. Every data item is distributed 
over the same clusters as the eventcount to which it is 
related. A <dataname>_OUT eventcount only informs everybody 
in the system that a slot in the respective data queues 
becomes available for overwriting (an important item of 
information for producer processes), and so these 
eventcounts, if distributed, will be transmitted alone, with 
no user shared data in the same Ethernet message. 

This logical interrelation between eventcounts and 
user shared data is kept in the relation table shown in 
Figure 4.3, which is a structure of 100 entries (the present 
implementation of RTC* allows for 100 eventcounts per 
cluster), which holds the eventcount_id and the number of 
related data items on level two, and information about up to 
10 data items for every eventcount on level three. Besides 
the knowledge about how many data items belong to some 
eventcount, the driver needs to know, where to find a data 
item, what is the items structure size, what is the data 
queue length, what is the next slot to be sent, and what is 
the next slot into which to put a received item. 

The relation table is built by the driver during 
system initialization by the procedure make_table, see 
Appendix A. This procedure reads the file relation.dat, 
which has to be present on the disk that keeps the cluster's 
software . 

The driver (see Appendix D) is a general system 
process that is identical at every cluster. The relation 
table is cluster specific and keeps cluster specific 
information only. The relation.dat file has to be set up by 
the lead programmer, who decides what application program is 
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Figure 4.3 The Relation Table. 

to be run at what cluster, and therefore knows what 
eventcounts and user shared data are needed at a cluster. 

The relation.dat file basically is a table 
consisting of five columns as shown in Table I. It keeps 
eventcount identification, number of data related to this 
eventcount, and for every data item the address of the first 
byte in its data queue, the length of the data queue (# of 
slots), and the length of the data item structure(# of 

bytes). The last line in the relation.dat file serves as a 

sentinel consisting of zeroes in all five columns. The 
procedure make_table expects the formatted indata to be in 
columns 5, 15, 25, 35, 45 respectively. This information is 
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TABLE I 

FILE RELATION . DAT 



evc_id 


numdat 


point 


qlen 


bytes 


col 


col 


col 


col 


col 


5 


15 


25 


35 


45 


01 


1 


8c58 


50 


6 


02 


3 


8d84 


10 


3 






8da2 


20 


5 






8e06 


2 


10 


05 


2 


8ela 


30 


5 






8eb0 


50 


9 


07 


1 


9072 


15 


5 


04 


1 


90bd 


20 


8 


00 


0 


0000 


00 


00 



read into the relation table entries evc_id, numdat, 
pointer, qlen, and bytes respectively. Next_in and next_out 
are initially 0 and therefore do not have to be read in. 

The information kept in the relation table suffices 
for the driver to do its job. The driver does not need to 
know anything about' the logical structures or names of data 
items. It treats a data item as a sequence of bytes, and is 
only interested in finding the correct sequence of bytes for 
transmission, or the correct place in Shared Memory to put 
the bytes after reception. Procedures make_message and 
process_packet take care of this. 

2 . Data Format 

A decision that had to be made was in what manner 
the data field of an Ethernet Packet should be used in order 
to exchange data in RTC*. The question was discussed whether 
to use different fixed formats for different situations and 
using the type field for identification of the format used 
in the data field. After recognizing the logical 
interrelationship between eventcount and shared data, that 
carries the possibility of uniquely identifying a group of 
shared data by its common eventcount, it was decided to keep 
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the data format as flexible as possible. 

The first four bytes of the data field will always 
keep the eventcount information followed by as many data 
items as are related to this eventcount. The maximum length 
of these data items together is restricted to 1496 bytes in 
order to respect the 1500 byte limit of the data field when 
the 4 byte eventcount information is included. This seems 
to be more than adequate for the purpose of RTC'~, and still 
leaves the possibility to transmit all data items as long as 
a single item is not longer than 1496 bytes, by logically 
grouping data items under eventcounts respecting this 
restriction. 

The eventcount is the identifying part, therefore 
only one eventcount is transmitted in any Ethernet packet. 

3 . Message Transmission 

Message transmission is triggered by an Ethernet Request 

Packet (ERP) available in the Ethernet Request Block (ERB) ; 

* 

more precisely, by an advanced eventcount ERB_WRITE 
indicating that there is an ERP in the ERB which has not 
been processed yet. The driver with its preference for 
outbound messages will start a transmit job as soon as 
possible. In the initialization part, the driver already has 
preset the first four bytes of the destination field and all 
six bytes of the source field. Refer to Figure 4.4 for the 
following discussion. 

Bytes five and six of the ERP are copied into the 
two high bytes of the destination field of the Transmit Data 
Block, making the first 14 bytes of the Transmit Data Block 
complete . 

Next a four byte overlay is put over the ERP, using 
a based variable [Ref. 11], after which the procedure 
make_message (see Appendix B) is called. 

This procedure first checks if the ERP contains an 
eventcount (in the present implementation only eventcount 
related ERPs are processed) . If byte one of the ERP 
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Figure 4.4 Message Transmission. 
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contains 00H, indicating EVC_TYPE then the first four bytes 
of the ERP are copied over into the first four bytes of the 
data field of the Transmit Data Block. 

Next a relation table look up is done under the 
respective eventcount_id and the number of related data 
items is found. If the eventcount id is not in the table, 
then there are no related data and the message is done, 
otherwise the first related data item is found, an overlay 
(1500 bytes in the present implementation) is aligned with 
the data queue, using the address information (pointer) of 
the data item. Now the slot number (next_out) and item 
size(bytes) are combined to an offset in order to find the 
first byte to be copied over into the Transmit Data Block to 
follow the eventcount information in the data field. The 
data item size (bytes) contains the number of bytes to be 
copied over. 

The next_out of this data item in the relation table 
is updated to the next slot number, and the loop starts 
again for the next data item related to this eventcount. 
Meanwhile also the total bytecount for bytes put into the 
data field of the Transmit Data Block is carried on. After 
all the related data has been copied over into the Transmit 
Data Block, this bytecount information is added to 14 (6 
bytes destination, 6 bytes source, 2 bytes type) and the 
resulting bytecount is used as a parameter in the procedure 
transmit_packet , which signals the ECCB that a message is 
ready to go and should be sent. 

Just before calling procedure transmit_packet , the 
driver calls ADVANCE ( ERB_READ ) , which makes the just 
processed ERP slot available for reuse. 

The ECCB copies the number of bytes signaled 
(minimum 60) into its transmit queue and puts the message 
out over the Ethernet. If necessary due to collisions, the 
transmission is repeated and only after the message was 
successfully sent does the transmitter become ready for the 
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next transmission, which is prepared by the driver in the 
above described fashion. 

4 . Message Reception 

Message reception is triggered by an ECCB interrupt 
signaling that there is a received message available in the 
ECCB's receive queue. Refer to Figure 4.5. The driver then 
initializes a DMA and the ECCB puts the message into the 
Receive Data Block in Shared Memory. After the message is in 
the Receive Data Block, the procedure process_packet (see 
Appendix C), is called. This procedure works similarly to 
the procedure make_message . 

Instead of getting the needed information from an 
ERP, procedure process_packet has to look up the first bytes 
in the data field of the received message. This 
implementation of RTC* neither uses the frame status and 
frame length information, nor the frame check sequence. 

First the procedure process_packet looks up byte one 
of the data field in order to check if the just received 
message contains eventcount information. If so, it finds out 
if the value of the just received eventcount is higher than 
the local value of the respective eventcount, because the 
message is of interest for this cluster only if the remote 
eventcount value is more advanced than the local one. 

If the remote value is higher, a relation table look 
up is made under the event count_id found in byte two of the 
data field. 

If there is no entry in the relation table for this 
eventcount, then no related data exists and the only thing 
to do is to update the local eventcount value. 

If an entry exists, then the address (pointer) of 
the first related data item is found, an overlay is aligned 
with the respective data queue, and the slot number 
(next_in) and the item size (bytes) are combined to an 
offset in order to find the first byte in the data queue 
that is to be changed. Then the number of bytes found in the 



46 




Figure 4.5 Message Reception. 
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item size information is copied over into the data queue, 
starting with byte five of the Receive Data Block's data 
field (i.e. the first byte of the first related data item 
received) . 

During this operation also the bytecount is updated 
in order to find the starting byte for the next related data 
item . 

Similar to the procedure make_message , the procedure 
process_packet updates the next_in information to the next 
slot number in order to be ready for the next incoming 
message bringing an update for this data item if any. 

After the first shared data item is copied into its 
correct slot in Shared Memory, the next related item is 
copied into its respective queue. After all received related 
data items of the received eventcount are updated, the 
eventcount is advanced to its new value, signaling the 
shared data status to respective consumers at this cluster. 
The procedure process_packet takes care of advancing the 
eventcount only after all related shared data items are 
updated, guaranteeing the consistency of eventcount values 
and data items . 

D . DATA SHARING 

It is obvious that data sharing using buffers in Shared 
Memory can only be achieved when producers and consumers 
agree upon, where to put and to find the respective data 
items. Also, this only works, if producer and consumer deal 
with the same item structure. 

In a system like RTC*, where probably many applications 
programmers write different system modules, these 
programmers have to agree upon the shared data names and the 
structures and queue lengths (at least for intracluster 
sharing) . 

Even though it would suffice to only declare those 
shared data items that are actually used in some process, 
the policy followed in the demonstration program was to 
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include a common declaration file in every module in order 
to ensure that sharing modules really work with the same 
data item. Following this example in a real program makes it 
easier to maintain all shared data declarations, probably 
done by the lead programmer. 

Applications programmers include the shared data file 
in their programs and only have to be concerned about the 
correct use of those items actually used in their programs. 
Table II shows the file share. del for the demonstration 
program . 



TABLE II 
FILE SHARE. DCL 



DECLARE 

(de_ptr , tr_ptr ,mo_ptr ) pointer, 

1 delta(0:19) based(de ptr) , 

2 dx fixed bin (7 V 
2 dy fixed bin (7 
2 dz fixed bin (7 



1 track(0:49) based(tr_ptr) 
2 x fixed bin (15), 

2 y fixed bin (15), 

2 z fixed bin (15), 



3 



1 missile order(0:49) based(mo ptr), 
2 launcher fixed bin (7), 

2 azimuth float binary, 

2 elevation float binary; 



This file ensures unique declarations for all user shared 
data in the whole system. 

Every user shared data item is declared as a queue that 
is based on a respective pointer. Using based variables 
provides the possibility that in spite of total user shared 
data declaration, only for those items that are to be 
resident in some cluster's Shared Memory physical memory 
space is assigned. This leads to efficient use of memory 
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space. As mentioned before, contiguous storage of data 
queues enhances the efficiency even more. 

This requires thoughtful assignment of addresses to the 
different data queues in the system. As for the relation.dat 
file and share. del file, the custodian for the assignment of 
pointers also should be the lead programmer. Applications 
programmers do not have to worry about this because they 
refer to a data item by dataname. Pointer assignments are 
kept in the file pointer. ass, which is cluster specific; the 
share. del file is the same for every cluster in the system. 
Table III shows the two pointer. ass files used in the 
demonstration program. 



TABLE III 
FILE POINTER. ASS 



/* 



this file keeps the pointer assignments 
for shared variables used at cluster 1 



unspec 

unspec 



(tr ptr)= ' 8c58 ' b4; 
(mo_ptr)= 8d84 b4 ; 



"7 



this file keeps the pointer assignments 
for shared variables used at cluster 2 

*/ 

unspec (tr_ptr)= ’ 8c58 'b4; 
unspec f de_ptr } = ' 8d84 ' b4 ; 
unspec (mo_ptr) = ' 8dcd ' b4 ; 



In order for processes to be able to really share data 
in Shared Memory, it is important that they find shared data 
under the same physical address. Under INTEL’S policy that 
calculates a 20 bit physical address from a segment and an 
offset, this implies that user shared data has to be found 
in the same segment, the pointer or logical address then is 
the offset in this segment. 
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In RTC* this is realized in using 800H as a data segment 
register value and using sixteen bit pointers for shared 
data starting at 8000H. The lowest Shared Memory address 
therefore is 800H*10H+8000H, which is equal to 8000H+8000H, 
or 10000H. The lowest byte of the Ethernet Request Block 
resides at the above address. 

The segment used by a process is defined in procedure 
create_proc. It is important that the parameters 4, 7, and 
8, i.e. stack segment (SS), data segment (DS), and extra 
segment (ES) in the create proc call are set to 800H when 
creating a process. As mentioned by Brewer ,when he 
describes user process creation [Ref. 1: p. 49], some 
PL/I-86 routines assume identical contents in the SS, DS, 
and ES registers. 
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V. CONCLUSION 



The goals of this thesis were achieved. The MCORTEX real 
time executive is extended to handle multicluster general 
inter-process data communication. An appropriate model for 
intercluster shared memory is implemented by partial 
replication of intracluster shared memory. Only PL/I-86 
modules were modified or newly added. 

The message exchange scheme is kept as flexible as 
possible, with the only restriction that the four bytes of 
eventcount information have to be put into the first four 
bytes of the data field of the Transmit Data Block, and all 
related data items have to follow in the sequence given by 
the relation table. The driver takes care of this. 

Maximum data length in a single message is restricted to 
1500 bytes in accordance with the Ethernet specification. 
This size seems more than adequate for the purpose of RTC*. 
If longer messages are needed in the system, a correct data 
exchange can be achieved by breaking up the message into 
smaller ones relating these to specific eventcounts. 

The driver takes care of correct message assembling and 
processing, and is -- as a special systems module with a 
dedicated board -- completely transparent to the 
applications programmer and user. The lead programmer will 
have to decide how to distribute different applications 
modules, and where to store data queues in Shared Memory. He 
or she will have to maintain the relation.dat file and the 
pointer. ass file, and also the agreed upon user shared data 
in the share. del file. 

In the current implementation of RTC* the dis tributivity 
of the eventcounts (and with these the dis tributivity of 
data items) have to be set at system initialization. This 
restricts the dynamic reconfiguration of the system after 
initialization. Future implementations should try to resolve 
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this restriction. A possible way might be to exploit the 
general broadcast situation of an Ethernet environment. As 
only one message can be on the Ethernet at a time, and as 
all stations on the net have to listen and cannot do 
anything else during this time, this situation could be 
exploited in the following manner. 

Use the eventcount_id as a kind of multicast address. As 
there is only one eventcount in any one message this is a 
unique identification of what information is carried in the 
message. Every cluster "knows” what information is needed at 
that cluster. If the eventcount_ids of related data items 
needed at some cluster are put into the group address table 
of that cluster’s ECCB , then every Ethernet packet that 
carries information of interest for this cluster will be 
taken in and processed. 

It is not necessary to keep the remote address for an 
eventcount in Common Memory. The information that an 
eventcount is distributed or not distributed, meaning a 
cluster external copy is needed or not needed, suffices. 
This distribut ivity information can be initialized for the 
initial system constellation. On reconfiguration, it could 
then be automatically and dynamically changed without having 
to shut down and reinitialize the whole system. 

After reconfiguration, only those clusters where actual 
changes were made broadcast the event count_ids of interest 
to the cluster. Every other cluster updates its 
distributivity information for those eventcounts. 

There was not enough time for the above described 
implementation in this thesis, but future work in this 
direction is highly recommended in order to make the total 
system more efficient, more robust, more survivable, and 
more flexible, requirements that are of utmost importance 
especially for military applications. 
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APPENDIX A 



PROCEDURE MAKE_TABLE 

Procedure make_table is the first procedure called by 
the driver. It sets up the relation table in local RAM of 
SBC 1 by reading the information from the file, 
relation.dat . 

The relation table is a three level structure that keeps 
the event count_id (evc_id) and the number of data items 
(numdat) related to this eventcount on level two and the 
data queue address (point), number of slots in dataqueue 
(qlen), number of bytes in item structure (bytes), next slot 
to be sent (next_out ) , and next slot to be received (next_in) 
on level three. 

There are maximum 100 level one entries in the relation 
table, because the maximum number of eventcounts at any 
cluster in the present implementation is 100. For every 
eventcount a maximum of 10 related data items are possible. 
The driver looks up an eventcount_id and finds all 
information necessary to either combine data items in the 
Transmit Data Block for transmission, or put received data 
items in their respective Shared Memory slots. 

Procedure make_table expects the indata evc_id at column 
5, numdat at column 15, point at column 25, qlen at column 
35, and bytes at column 45 in the relation.dat file. 
Next-out and next_in are initially 0 and do not have to be 
read. 
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X*##################### ## ##*<#*<## ## ## ##*,<:##### # # ##)*####### #3* V >* # 

*** PROCEDURE MAXE_T ABLE R.Haeser, Dec 1985 *** 

# # # __ x y z # 

*** This procedure reads relation values from file * ifV 

*** RELATION.DAT into the relation table. *#* 

#^*}^^^ijC#^S^^5^^^;^5^5>(^#^^^^^^^^^^5^ 5 « ! ^.^ t j(.^ c J t j{ :5 . I j( ;; i.3{ t 3^^.^ £ .j c ^ !l tay.j. J ( e ^j. : { t | i jj^5je.. ( .j.. 3 j,y. 



make_table: procedure ; 

declare 

relation file, 

(j,i) fixed bin (15), 
eof bi t (8 ) ; 

open file (relation) stream input; 
i=0; 

eof='0'b4; 

do while (eof='0'b4) ; 
i=i+l ; 

/* read data from relation.dat file */ 
set file (relation) edit (rel_tab( i ) .evc_id , 

rel_tab'i ) . numdat ) 

(column ' 5 ) , b- 1 ( 2 ) .column ' 15 ) , f ( 2 ) ) ; 

do j=l to ( rel_tab( i ) .numdat ) ; 

/* read data for all related items */ 
get file (relation) edit 

(ur.spec(rel_tab(i).data(,i) . coin t ) , 
rel_tab ( i ) .da ta ( j ) . a len , 
rel_tab(i) .data(j) .bytes ) 

(column (25) ,b4(4) .column (35) , f ( 4 ) .column (45) , f (4 ) ; 
maxa bytes=max (max a bytes, 

rel_tab(i).data(,1).bytes Jic rel_tab(i).data(j).Qlen); 



end ; 

/* if sentinel is reached */ 
if rel_tab (i ) .evc_id = '00'b4 then 
d o * 

eof = ' 1 'b4J 

put skip lis t( 'lonsest data aueue at this cluster:', 
maxabytes , ' bytes ' ) ; 

end ; 
end ; 

end make table; 






55 



APPENDIX B 



PROCEDURE MAKE_MESSAGE 

Procedure make_message is called by the driver when 
there is an Ethernet Request Packet in the Ethernet Request 
Block that has not been processed yet. 

It checks the ERP for eventcount type, and if the ERP 
contains eventcount information, it sets up the data field 
of the Transmit Data Block. The eventcount information is 
always put into the first four bytes of the data field, 
followed by all data items related to this eventcount in the 
sequence given by the order of these data items in the 
relation table. 

Procedure make_message also keeps track of the bytecount 
of the total message, an information needed by the ECCB for 
transmission. 
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ft###**# ## ### age #){'*'¥ 4* ### # 

#################:£#:£#########:$:# ## ## ## # # # # # # # # # # ## # # ## ## #;* v # *t 

*** PROCEDURE MAKE_MESSAGS R. Haeger, Dec 19 = 5 #** 

*#* **- 

*** This procedure builds the Transnit Data Block: for *** 
*** a message to be transmitted over the Ethernet. J "‘* 

J? aft* =? ####!(« # a*##### jSjJcs*# V v e ^.^^ J j t ^^ c ^.^ : j t 3) t ^ : ^ tl v : ^ ! ;j c;4: w ) ^j tifitzxm-xfrf# 



make_message : procedure ; 
declare 

ia t_pt r pointer, 

dat_vec t ( 1500 ) bit (8) based (dat_ptr), 

( next_out , r ,.} ) fixed bin (7), 

(off .start .last ,k) fixed bin (15); 

/* check for eve */ 
if erp_vect ( 1 )=EVC _TYPE then 
do ; 

bytecount=4J 
do k=l to 4; 

/* put eve info into data field */ 
transmit _data_block.data(k )=erp_vect ( k ) ; 
end; 

/* check message 

put skip lis t (':::: ' , transm it_da ta_block.data ( 1 , 

transmit _data_blcck.data (2) , ' : : ' , 
transmitdata_block.data(3), ' : : 
transmit _data_b lock. data (4) , ': : : : ' ); 

*/ 

r=l ; 

/* fird respective relation table entry */ 
do while ( ( rel_tab { r ) . evc_id "= ero vect(2)) 5. 
(rel_tab(r ) .evc_id ~= '?0 -7 ’b4)); 

r=r+l ; 
end; 

/* if eve entry */ 
if rel_tat ( r ) . ev c_id ~= '00'b4 then 
do; 

/* for every related item */ 
do .1=1 to rel_t ab ( r ) . numda t ; 
start=by tecoun t + 1? /* find where to put * / 

las t = rel_ tab ( r ) .data ( j ) . by tes ; /* how long it is */ 
by t ec oun "t = by te coun t + last; /* keep track */ 
dat_ptr=rel_tab( r ) .data ( j ) .ooint » /*align datvect*/ 
next_out = rel_tab(r).data(,i).next_out; 

/* compute offset of item in data oueue -/ 
of f=( rel_tab ( r ) .da ta ( ,1 ) . by tes * next_out) + l; 
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/* compute next slot number to go */ 
rel_t ab( r ) .dat a ( j ) .next_out=mod ( next_out + 1, 

rel_tab(r) .data ( j ) .a lea ) ; 

do k=0 to (las t-1 ) » 

/* put item's bytes into data field */ 
transmit _lata_block. data (k->-s tart )=dat^vect (k+off ) ; 
end ; 
end; 
end ; 

/* compute total bytecount for message */ 
bytecount=bytecount + 14; 
end; 

else do? / # if not eve */ 
end; 

end make message; 
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APPENDIX C 



PROCEDURE PROCESS_PACKET 

Procedure process_packet is called by the driver when 
there is a newly received message in the Receive Data Block. 

It checks the received data for eventcount type, and if 
the message contains eventcount information, it checks if 
the received remote eventcount value is higher than the 
local value of the respective eventcount. Only if the remote 
value is higher than the local value, it processes the 
received message. Using the eventcount_id in byte two of the 
data field, a relation table look up is done and all 
received data items are put into their correct slots in 
Shared Memory. 

After all data items are placed correctly, the local 
copy of the respective eventcount is updated by calling 
ADVANCE (EVC) . 
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# # 5je # # # # # # 5{C # ## # # # # # # # 5jC # # # 5{C # # # # ## j}C # # # # # # # Sj€ # ## SjS # # # # # # # S£ 3* 

Jfc############ ######### ### ######## ###### ######## ####### ###### 

*** PROCEDURE PRCCESS_ PACKET R.Haeeer, Dec 1995 *** 

S^SjtX* — — — ##5? 



*** This procedure processes received messages. 

*** It takes the data from the Receive Data 31ock and 



*** put every item in its correct slot in Shared Memory. **- 



*** It also c 

»'< o). »*« %*> v ( . vU «L> *A» «>/ 

V '.* V »i* 'I* '(* T *1'V O' O' 'i' 



alls for an update of the ever.cour.t valu 

^ sU u# v<# %•# ju j# «.•> ju %u o# «ju j# 4# kU *u ^ v# ^ ^ ^ ^ >v 

♦ p V #P *1* i*p #|% ^ - P rp i»p #P ^p /p -y* >P *)* #p #p ^ #P 'P ^p #p * p /p ^p *Tp ^p 



process_packet : procedure? 

DECLARE 

evcid hit (3 ) , 
local_evc_value hit (16), 

(dat_Ptr,p) pointer, 

remote_ev c_value hit (16) based (p), 

da t_vec t ( 1507* ) hit (8) based (dat_otr), 

( of f , s tar t , last , k ) fixed bin (15), 

( next_in , r , j ) fixed bin (7); 
put skip list(' receiving'); 

/* check for eve */ 

if receive_data_block.data(l)=evc_type then 
do ; 

p = addr(receive_data_block.data (3) ) ; 
evcid=receive_lata block. data (2); 
lo cal_evc_value = read(evcid); 
if local_evr_value < remote_evc_value then 
do ; 
r=i; 

/- find eve entry in relation table */ 
do while ( ( rel_t ab ( r ) . evc_i d ~= evcid) & 

( rel_tab ( r ) . evc_id ~= '00'b4))J 

r=r+l ? 
end ; 

if rel_tab (r ) .evc_id ~= '00 'b4 then 
do ; 

byteccunt=4; /* jump over eve info */ 

do ,1=1 to rel_ta b(r ) .numdat ; 

start=bytecount+l ; /* compute start of item */ 

last = rel_tab (r ) .data ( j ) .bytes ; /* and length ***/ 
bytec ount=bytecount+las t ; /* and item's end */ 

next_i n=rel_tab{ r ) .data ( j ) . next_in i 
/* compute offset in data aueue */ 
of f=( last-next _in ) + i; 

/* compute next slot number to fill */ 
rel_tab( r) .data( j) .next_i n=mod (next_in+l, 

rel_tab(r).data(j).alen); 
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dat_ptr=rel_tab( r ) .data (j ) .point ; /* align datvect*/ 

do k=9 to ( last - 1 ) ! 

/* put item bytes into data aueue */ 
dat_vect(k+off)=receive_data_block.data(k+start); 
end ; 
end 5 
end; 

/* update local eve value */ 
do while (local_evc_value < remote_evc_va lue ) ; 

call advance (evcid); 

local_evc_value = add2bitl6( local_evc_value , '0001 'M) ; 
end ; 
end ; 

else do; /* if not eve */ 
end ; 



call disable_cpu_interrupts ; 
end ; 

end process_packe t ; 
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APPENDIX D 



THE DRIVER 

The driver is the software link between a cluster and 
the ECCB that hooks up a cluster onto the Ethernet. It 
manages all cluster external message exchange (transmission 
and reception), and sets up the clusters communication 
ability in the first place. 

The driver resides in the user area of SBC 1, which is 
dedicated to serve as the cluster's host. The executable 
file names are C1PR0C.CMD and C2PR0C.CMD for the two cluster 
constellation of RTC* in the AEGIS lab at the US Naval 
Postgraduate School. 

The LINK86 Input option is used to link files sysinitl, 
sysdev, asmrout, and gatemod into C1PR0C. Sysinit2, sysdev, 
asmrout, and gatemod are linked into C2PR0C. 

Cluster specific information about the creation and 
distribution of eventcounts is contributed by sysinitl and 
sysinit2 respectively, which are the main procedures for the 
linkage. Additional cluster specific information is read 
from the address.dat file and the relation.dat file during 
execution at runtime. The %included files sysdef.pli and 
NI3010.dcl provide system-wide information. 
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# ## # ## # # 5? a}: 3$: # sje# # 3 * ajc 3£# # ^ ^cajc #3$e # *# # 3 * 3$c 3 * 3* # # 3$C3£ 3fr 3 * it sjc # 35 c 3 * ## 3 * # 3 * 3 * # a$c ## # 3£ :£ 

# # # # # # # # ^r # # * # # # a^ # # * aC< it # # # 3* * # # 3^ s$c # 3 jc j$c jjc # s$c s$e # # # it it it # # # 3 $c afc 3* # it # # # it 3 ^ 3 $e 3* 



*** C1PR0C.INP file *** 

tftf# iS*# 

*** This file is used to link system initialization, *** 

*#£ driver, assembly language routines, and gatemodule *** 
*** into C1PR0C.CMD, the executable file run on S3C 1 at *** 
*** cluster 1. *** 



3*C 3* 3^ 3^ ## 3^ # # 3*# $ 5jc ?;c it it 5jc # #3$C 3j< 5^# X' $$ # 3* # # 3{t # # # # #3^ ## 3* 

clproc = 

sysini tl [code[ab[439] ] .data [ab [8001 , n [0l ,ad [82] ] .man [all 1 ] , 
sysdev , 
asmrout , 
gat emod 



it # # # 3*C if. 3jt 3{C 3* 3* # # # 3* * 5jS 3{? 3* *C # it S£ # # # # 3* 3{C # # S{C 3}C # # 3$C if # 3{? *C # # if 3$C # # 3* 3?: 3jC 5{C 3fc if. # 3ft 3£ 3>C 3* if. 3? # # 

3i? # 3^ # sfc # if. it it it # # s{c # # it # a{c 3^ # if. it it #. it 3^ sjc 3*: 3^ s$c a(^ 3}c sjc 3^ ^ 3^ 5^ it * # X' ^ ^ ?!« 5r >r # # 3}: ^ y 



3jt Sjt ^ 


Cluster 1 


RELATION .DAT file 




«*« .14 «t« 

•«» •nr* »r 
^3^ 3$C 


**< s This file 


keens the 


data used 


to build 


the relation 


*p 


,!t:<t!!t table: 










WU»«> OL, 

' 1 ' 't' rr- 


*** 










k>» 

-t 5 -nr* *v 


*** eve id 


numdat 


noint 


a 1 en 


bytes 


3^ 3ji 3$C 












.•, ^ 
'r* 'i* "I'* 


col 


col 


col 


col 


col 




5r«# 5 


15 


25 


35 


45 


3^S ^ SjC 


V* »•' *v y» «-v ju «i» J« >•/ *u vV «*« »'* »'» -Xr * 1 # «u v* Vr »•<* <>v 
v *r <r v t v •r n* v*r *r •’r 'r '■»' t f *r v v 'r ?r v 


3^ :}C 3jt # 3}S 3^ 3^ 3^ # 


juw**>o**v^wu 
' f’V'r ¥n'*i»n*'r 


T T 'I' I s T 'I' 'I s 'l' « 1 * V T T -l* 


«u *v «u »<» 
TT T'r 


01 


1 


8c58 


50 


6 




03 


1 


8d84 


50 


9 




00 


0 


0000 


00 


0 





it it it # 3jJ s;< 55c 3^ 3* it 3^ sjc 3jc it it # it ^ 3^ ^ s?c # X« 3{s ^ ^ 3{C 3J; 3jC # 3^: 3? 3^ # it # # # ^ ^ ^ ^ 5;c^ ^ 5n 

X<^3^^3^3t:^C3^XC3t:3{C3^^3!<3;C3:C^^3{<3{<3«C^3j;^^3^^^3}C3{C^3:C3^>J;3{<3>:3^3^3^«^^3;C3{C3{:3;iXC3|t3:t3{C3;:^^3^^^3^^^3jC 



5!S5r^ 



Cluster 1 ADDRESS . DAT file 



- 'T' -V* 'l' 



This file keeps the number of ?roup addresses, *** 

*** the cluster's grouu address(es) and the cluster's *** 

*** source address. 5?:::: ' ,:: 

3^3}C^S^^5t;^^3*C3^3}C3;t>iC^^3^^^^3^3^3{e3}:; i 't^^^^C3^^^3^3jC3^3}C3fC3f:3^^3}C3jC3{C^C3f:3^3jC3}C^3^^^^^3}t^3>:^^y ^ 



1, 

'00000000 'b , 'e0000001'b, 
'00000000 'b , '00000001 'b 



£####* ;Jt 3'^3 , l <^^3|s4;3^:^3jC3}C>;?3{::^3^3;C^3^3^^^3^3^3 l , S X XX* ##****##** XX* 
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######### 

# # # *fi # # * 3$C # # J$£ # # # S*C 5?: 3?: # # 5J< # # # JjC # # # # # # # # # # # # tf # # # # # # 3?C # # # # # # 5jC # # # 5jt # # # # 

*** STSINIT1.PLI file *** 

:Jt s}e >jc ### 

*** This is the system initialization procedure for *** 

*** cluster 1 . . *** 

*;Je# #####*#### 5}: sjc sit# sfc### ###### # # # # # 



sysinitl: proc options (rrain)J 

^include 'sysdef . pli ' »* 

%replace 

EVC_TY?E by '00'b4» 

/* main */ 

call def ine_clus ter ('0001'b4); 

/* must be called prior to creating eve's */ 



/#£*:;< USER 



call create_evc (TRACK_IN)» 
call create_evc (TRACK_OUT); 
call create_evc (MISSILE_OREER_IN ) J 
call create_ev c (MISS ILI_ORDER_OUT ) ; 

/*** SYSTEM ***/ 

call create_evc (ER3JREAD); 

call create eve (ERB_WRITE); 

call create_seq (ER3_WR ITE_REOUEST ) * 

/* distrib. map called after eventcounts have 
been created */ 



call dis t ribut icn_map (EVC_TYPE, TRAC K_ IN , '0003'b4); 

/* local and remote copy of TRACK_IN needed */ 
call dis tribut ion_map (EVC_TYPS. MISS ILE_ORDER_OUT , 

'0003 'b4 ) J 

/* local and remote copy of MISSILE_ORDER_OUT 
needed */ 

/* create driver #/ 
call create_proc ('fc'b4, '80'b4, 

'26a5'b4, '0800'b4, '005f'b4, 

'0439 'b4, '0800 'b4, '0800'b4); 
call await ('fe'b4, '01'b4)» 

end sysinitl; 

#### #### #################################################### 
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3fc3£3*3£###3^###3£3£s^3£;£3£3(c#3£*4# ######### ## 



# # # 3?4 # 5|< 3^4 3^ SjO* # #3}S 3j* S^ 3;r3^^^: ### ## jjc J^C # # # 3^ ## # Sj« 3;c 3^ >|4 sj: 3jc 3^ 3^ 3^ # # *4 3^ # 3|4 3j4 3^ 3^ 3* 3;c 3^ 3^ 



*** C2PR0C.IN? file *** 

#*# ## V 



*** This file is used to link system init ializatio , *** 

*** driver, assembly language routines, and gatemodule *** 
*** into C2PR0C.CMD, the executable file run on SBC 1 at *** 
cluster 2. * s *' ,: 

# 3jt 3^ 3^ # # 3^ * # # # # # 3* 3}4 3* 3jC 3^ 3£ Jfc # # # # 3* 3(4 3* 3* 3* 3$C 3* 5jC 3* 3* 3(4 3(4 3(4 3* 3£ 3(4 3jC # 3(4 3(4 3* 3£ 3(4 3(4 3(4 3* * 3(4 S£ 3(4 3* 3(4 3(4 3* 3£ 3 (4 



c2proc = 

sysini t2 [code [ab [43911 .data [ab [800] ,m [0] ,ad [92] ] , map [all]] , 
sysdev , 
asmr out , 
gatemod 



3(4 3(4 3(43(4 3^ 3(4 3(4 3(4 3^ 3*4# 
3<C 3jt # 3|? 3(4 3jC 3(4 3»4 3(4# 3(4 



5jS 3^ # 3(4 3j? # 3£ # 3(4 3(4 3$4 3(4 3(4 3(4 3^ 3}C 3(4 3(4 3(4 3(4 3(4 3(4 3(4 3j« 3(4 3* 3(4 # 3(4 3£ 3(4 3jC 3^ 3(4 3(4 3^ 3(4 3(4 S£ 3(4 3£ 3(4 # ^ 3(4 3^ # # # 

3 ;: 3 ;: 3(4 3 ;: 3 j? # sjc ^ s (4 3(4 3 ^ >;< s (4 3(4 3 ^ # s (4 3(4 3 ^ 3(4 3(4 3 ;; 3 jc 3 |< 3 ;: 3 ;: # 3 ;: sjc 3(4 s;c 3 ^ s{c 3 ;; s;c 3 ;« s;c 3 ^ 3 ^ ^4 3 ^ 3 ^ 3 ;^ s£ 



Cluster 2 RELATION - DAT file *** 

— — — — — — — —— ——— — — — — — — — — — — — — — — — — — —— — — — —— — — — — ——— — — —— — — — — — ^ 3^ 3JC 



*** This file keeps the data used to build the relation *** 
table: *** 

•J* *W >V *** *Ar 

•r v v ‘t*n*'r 



s^^csjc 
3{4 3^3^ 


evc_id 


numdat 


point 


a len 


bytes 


V -r 
3J4 3J4 3jC 




col 


col 


col 


col 


col 


nr*r ^ 




5 


15 


25 


35 


45 


•*.' n» 


3}C3^3j43j4 3{C^3^3^3jC^4^C^3{C3t:^C3^3jC^C^4 3t4 3^^: 3^ 3^ 3{C 3^ 3^ ^4 3{C # 3^ 3^ 3ftS 3{C 3{C 3j4 3{C 3^ 3^ 2 


>£3£3£3(C3>:3}C3{C##3£:}C3£3£3}43£3}: 


3^4 3|C 3^4 3{4 3^4 



01 


1 


8c58 


50 


6 


05 


1 


8dS4 


20 


3 


03 


1 


8dcd 


50 


9 


00 


0 


0000 


00 


0 



^3^3^3^3^3f:3}C>JC3t:3^^3;i3^ 3{C 3^C 3jC ft 3^ 3^ 3^ 3}: 3^ 3(C 3{4 3^ # ^ 3^ 3jc 3^ 3^ 3^3jC 3{C ^4 3^ # 3^ 3j< 3^3^ 3^ 3^ # 3^ 2^ 3^ 3^ sj4 3{? 3^ 3^4 3|i # SjS Sji 

3j4 3^4 3j4 3^4 >JC3{C 3^3^>;4^4 35S 3^ ^4 3^ 3(< 3j4 3^ 3^ 3^4 ^ # 3^ 3^ ^4 3^ # 3^ 3^ 3^ 3^ JjC 3^3^3^3^3^>^3t4 3;4 3^3jC3^3^3}C3^3^3^3^3^3^3>:3^3^3^3;4 3^3^3^3^3J4 

*#* Cluster 2 ADDRESS . DAT file *** 



*** This file keeps the number of group addresses, *** 

*** the cluster's grout) address (es ), and the cluster's *** 
*** source address. * 5: '' 5:{ 

3 ^ 3 { 4 ^^ 3 ^ 3 ^^ 3 ^ 3 ^ 3 ^y < 4 ^ 3 jC 3 ; 4^4 3 }: 3 ^^ 3 ^ 3 {eX 4 3 ^ 3 {C 3}4 3 ^ 3 >: 3 j 4 3 {Ca^^C 3 ^ 3543{4 3 jC 3 ^ 3 ^ 3 jC 3 ? 3 ^^^ 3 p 3 lC 3 )C 3 ^ 3 ^ 3 ^ 3 ^ 3 ^ 3 ^ 3 ^ 3 ^ 3 ^ 3 jC 3 f: 3 ^ 3 ^ 3 ^ 3 ^ 3 ^ 



'0D0 00000 'b, '00000010'b, 
'00000000'b, ' 0000001 0 ' b 



* # jje # # >,•« ^ a}: j)e # # >(; # a}: s*c # # sjc ^ # >? jjt # ^ ^ #sft # ^ # >r ^ ^ ^ « J? # ^ ^ # 5^ « =P »« # # >!« ^ 
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############# #*###3^### 3|«J: >}C Sfc # SjC# # SjS^C 3^ £ 3jOjC # 3*C# 5jC ## 3fc# # 3^ ### ^ # # ## # 



## 



*** SYSINIT2. PLI file *** 

>}e^C5{c 



*#* This is the system initialization procedure for *** 

*** cluster 2. *** 



sysinit2: proc options (main); 

^include 'sysdef .pli ' ; 

^replace 

EVC_TYPS by '00'b4? 

/* main */ 

call def ine_clus ter ('0002'b4); /* must he called prior 

to creating eve's */ 

/**** USER ***** / 

call create_evc (TRACK_IN)» 

call create_evc (TRACK_0UT); 

call crea te_evc (MISSILE_ORDER_IN) ; 

call create_evc <M ISS ILE_ORDER_OUT ) ? 

call create_evc (DELT^_I N I); 

call create_evc (DELTA_0UT); 

/*** SYSTEM ***/ 

call create_evc (ERB_READ); 

call create_evc (ERB_WRITE); 

call create_sea ( E RB_WR I TE_ REQUEST ) ; 

/* distrib. map called after eventcounts have 
been created */ 

call distribution_mao (EVC_TYPE, TRACK_0UT , '0003'b4)J 
/* local and remote copy of TRACK_IN needed */ 
call di st ributi on_map (EVC_TY?E, MISS ILE_ORDER_IN , 

'0003'b4 ) ; 

/* local and remote copy of MISS ILE_ORDER_ IN needed */ 
call create_oroc ('fc'b4, '80'b4, 

'26a5'b4, '0800'b4, '006b'b4, 

'0439 'b4 , '0800 'b4 , '0800'b4)J 
call await ('fe'bd, '01 'b4); 



end sysini t2; 

### #######❖ # # # # # 3|C 3^ # # # ;JC # 3{C 3ji 3jS 



3jC#3£3jC 3|CJfc 3}e3fc3;:s£3£3£3iC35c:{:3{es{e3SC 
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/** SYSDEF FILE SYSDEF.PLI David J. 3REVER 1 SEP 84 **/ 

/** This section of code is given as a PLI file to be **/ 
/** %I NCLUDE 'd with MCORTEX user prosrams. ENTRY **/ 

/** declarations are made for all available MCORTEX *'•'/ 

/** functions. **/ 

/ #####*#*##**###*** ***#*# / 

/ # # # $ # sj€ # #3jt jfc # # J*C # Sfcjfc 5fc ## ## ## # 3fiC >SC 9fiC #5$C aQc ## 3$: # # # ^fC j'.Cj'c # )£ # 3jC # # jfc Sjc 3j« # # # sJC # # # # # # / 



DECLARE 

advance ENTRY (BIT (8) ) , 

/* advance (e vent_coun t_id ) */ 

await ENTPY (BIT (8), BIT (16)), 

/* await ( event_count_id , awaited_value ) */ 

create_evc ENTRY (BIT (8)), 

/* create_evc ( event_count_id ) */ 

create_proc ENTRY (BIT (8), BIT (8), 

BIT (16), BIT (16), BIT (16), 

BIT (16), BIT (16), BIT (16)) , 

/* create_proc (processor_id , proces sor_priori ty ,*/ 
/* s tack_oointer_hiehes t , stack_ses, ip */ 

/* code_seg, data_seg, extra_seg) */ 

create_sea ENTRY (BIT (3)), 

/* create sea ( seauence_id ) #/ 

preempt ENTRY (BIT (8)), 

/* preempt (processor_id ) */ 

read ENTRY (BIT (8)) RETURNS (BIT (16)), 

/* read ( even t_coun t_id ) */ 

/* RETURNS current_event_count */ 

ticket ENTRY (BIT (8)) RETURNS (BIT (16)), 

/* ticket ( seauence_id ) */ 

/* RETURNS un ia ue_t i cket _value */ 

def ine_cluster ENTRY (bit (16)), 

/* def ine_c luster ( local_cluster_address 

distribution_mao ENTRY (bit (8), bit (3), 

/* di st ributi on_map (distribution_type , 

cluster _addr ) 



) */ 

bit (16)), 
id , 

*/ 



6 ? 



add2bitl6 ENTRY (3IT(16), BIT ( 16) ) RETURNS (BIT (16)); 
/* add2bi t 16 ( a_16bit_#, ano the r_16b i t_# ) */ 

/* RETURNS a _16bit_# + ano ther_16bi t _# */ 



%replace 





EV C$ ID 's *** 










(1) USER 






*/ 




TRACK IN 


hy 


'01 'b4 , 






TRACK OUT 


by 


'02'b4, 






MISSILE ORDER IN 


by 


'03'b4, 






MISSILE ORDER OUT 


by 


'04'b4, 






DELTA IN 


by 


'05'b4, 






DELT A_OUT 


by 


'?6'b4. 




/* 


(2) SYSTEM 






*/ 




ERB READ 


by 


'fc'b4. 






ERB_WRITE 


by 


'fd'b4, 






*** SEQUENCER NAMES 








(1) USER 






*/ 


/* 


(2) SYSTEM */ 










ERE_WRI TE_REQUEST 


by 


'ff 'b4. 





*** SHARED VARIABLE POINTERS *** 
fl) USER */ 



/* (2) SYSTEM */ 



block_ptr_value 


by 


'8000 'b4 , 


xmi t_pt r_value 


by 


'8078 'b4, 


rcv_pt r_value 


by 


'8666 'b4 , 


END_RESERVE 


by 


'FFEF 'b4 » 



£ # sje # * ^ # # # # # s}c # ^ j): Jjt # * # # >)! sjc sje # aje # s* # Xe # # # X« * # # Xs Xt 5}: # # Xt X« a* s*e Xc =Jc Xc * Xc # sjc * sjc if * Xc 
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*** NI3010.DCL file *** 

# sjc aj< # « *< 4: # * * # <c # if s*{ s(< # # * # aje # # <« * # # # # # # £ # # *« # # *fi # # 4= # # # # # # * # # 4= # V # * * £ # # 

^replace 



/* 



I/O oort addresses 



These values are specific to the use of the 
NI3010 MULTIBUS to ETHERNET interface board 
to the I/O port address of '00b0' hex (done 



switch ) 
reflect 



will reauire 
that change. 



a change to these 



INTERLAN 
Any change 
so with a DIP 
addresses to 

*/ 



c ommand_regi s ter 
command_sta tus_register 
transmi t_data_regis ter 
interrupt_status_reg 
inter rupt_enable_ re gister 
high_byte_rount_reg 
lcw_byte_cou.nt_reg 

/* end of I/O port addresses 



by 


'b0 


'b4, 


by 


' bl 


'b4. 


by 


'b2 


'b4 , 


by 


'b5 


'b4. 


by 


'b5 


'b4. 


by 


'be 


' b4 , 


by 


'bd 


'b4. 


*/ 







/* Interrupt enable status 
disable _ni 3010_interrupts 
ni3010_intrpts_disabled 
receive_block_available 
transmi t_dma_d one 
receive_dma_done 

/* end register values */ 

/* Command Function Codes 



register values */ 
by '00'b4, 
by '00'b4. 
by '04'b4, 
by '06'b4, 
by '0?'b4, 



*/ 



module_interface_loopback 
i nterna 1_1 oopback 
clear_loopback 
go_of f 1 ine 
go_online 

onboard_di agnostic 
clr_insert_source 
load_transmit_data 
1 oad_and_send 
1 oad_groun_addres se s 
reset 

/* end Command Function Codes 

J$C ❖##### ###❖## ########### #3jC3$C #### 



by 


'01' 


'b4, 


by 


'02 


'b4. 


by 


'03' 


'b4. 


by 


'08' 


'b4. 


by 


'09' 


'b4. 


by 


'0a 


"b4 , 


by 


'0e ' 


'b4. 


by 


'28' 


'b4. 


by 


'29 


'b4, 


by 


'2a' 


'b4, 


by 


'3f ' 


'b4J 




*/ 
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## ###### ###### ###### ####:£### # 

Sjc # # # # J$C # # # # 3*S # 5$C 5jc # # 3$C # # # # # # # # # # # # # # # # # # # # # # 3jC £ 3jC # 3*S SjC # # # ij£ # # # # # # # 5jC # SjC 

*** SISDEV.PLI file (driver) *** 



sysdev: procedure* 



/* Date: 25 NOVEMBER 1985 

Programmer: Reinhard HAEGER 

Module Function: To serve as the Ethernet Communication 

Controller Board (N 130 10) device 
handler (driver). This process is 
scheduled under MCORTEX and consumes 
Ethernet Reauests Packets (SRP) 
generated by the SYSTEM$IO routine in 
LEVEL2.SRC . 

It creates a relation table that keeps 
information about the interrelationship 
between eventcounts and user shared 
data, and uses this information for 
producing and processing Ethernet 
messages . 

This driver is the version orovided by David Brewer 
modified in order to ensure system-wide data sharing. 
The Tran smi t_Da ta_Rlock and the Receive_Data_Bl ock were 
changed to keep 1500 bytes of data. 

New nrocedures Make_Table and Make_Message were added, 
and procedure Process_Packet was comoletely changed to 
provide cluster external user shared data exchange. 
Procedure Transmi t_Packet was modified to provide 
flexible exact message length to the ECCB if the length 
is greater than 60 bytes, and minimum message length if 
the message is 60 bytes or less. 

*/ 



^replace 



evc_type 




by 


'00'b4 


erb_bl ock_ 


len 


by 


20, 


erb_bl ock_ 


lenjnl 


by 


19, 


inf ini ty 




by 


32767J 



^include 'sysdef .pli ' ; 
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DECLARE 



1 erb( 0 :erb_block_len_ml ) based (block_ptr), 
2 command bit (8 ) , 

2 ty pe_name bit (8 ) , 

2 name_value bit (16), 

2 remote_addr bit (16), 

1 transmi t_data_block based (xmit_ptr). 



2 


destination_address 


a 


bi t 


(8) , 


2 


destina tion_address 


_b 


bit 


(8) . 


2 


lest ination_addr ess 


c 


bit 


(S), 


2 


destina ti on_addres s 


_d 


bit 


(8), 


2 


destination _address 


e 


bi t 


(8) . 


2 


destina tion_addr ess 




bi t 


(8) , 


2 


source_ address _a 




bit 


(8) , 


2 


source_address_b 




bit 


(8), 


2 


source _address_c 




bit 


(8). 


2 


source_address_d 




bit 


(8). 


2 


s ource_ ad dress _e 




bit 


(8) . 


2 


source _address_f 




bi t 


(8) , 


2 


type_f ield_a 




bit 


(8) . 


2 


type field b 




bit 


(8), 


2 


data (1500) 




bit 


(8) , 



recei ve_da ta_ bl ock based 


( rev 


_pt r ) 


» 




2 


f rame_s tatus 




bit 


(3) 


f 


2 


null_by te 




bit 


(8) 




2 


f rame_len,sth_lsb 




bit 


(8) 




2 


f rame_length_msb 




bit 


(3) 




2 


destination_address 


a 


bi t 


(3) 




2 


destina ti on_address 


_b 


bit 


(3) 




2 


dest ina tion_addres s 


c 


bit 


(8) 




2 


destina tion_addr ess 


_d 


bit 


(3) 




2 


destination_address 


e 


bit 


(8) 




2 


destina ti on_add res s 


_f 


bit 


(8) 




2 


source_address_a 




bi t 


(3) 




2 


s ource_addres s_b 




bit 


(8) 




2 


source_address_c 




bit 


(8) 




2 


source^ address _ d 




bit 


(3) 




2 


s ource_addres s_e 




bi t 


(3) 




2 


s ource_address_f 




bit 


(3) 




2 


type_f ield_a 




bit 


(8) 




2 


type field b 




bit 


(8) 




2 


dataTl500 ) 




bit 


(3) 




2 


crc msb 




bi t 


(3) 




2 


crc_upper_middle_byte 


bit 


(8) 




2 


crc lower middle byte 


bi t 


(8) 




2 


crc_lsb 




bit 


(3) 
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e_ptr pointer, 

erp_vect(4) bit (B) based (e_ptr), 
(maxqbytes ,bytecount ) fixed bin (15), 

1 rel_tab ( 100 ) , 

2 evc_id bit (8 ) , 

2 numdat fixed bin (7), 

2 data ( 10 ) , 

3 point pointer, 

3 qlen fixed bin (7), 

3 bytes fixed bin (15), 

3 next_out fixed bin (7), 

3 next_in fixed bin (7), 

(xmit_otr, rcv_otr ,block_ptr ) pointer, 
index fixed bin (15), 

(addr_e, addr_f) bit (8), t 
address file, 
copy_ie_reei ster bit (8), 

( cluster_addr ,erb_wri te_value , i ) bit (16), 
( .1,k) fixed bin (15) , 
reg_value bit (8) , 

wri te_i o_port entry (bit (8), bit (8)), 
read_io_port entry (bit (8), bit (8)), 
ini tiali ze_cpu_int er rupt s entry, 

enable_cpu_interrux>ts entry, 

disable_cpu_interrupts entry, 

write_bar entry (bit(16))5 

/* end declaration */ 



^replace 

/* codes specific to the Intel 8259a Programmable 
Interrupt Controller (PIC) */ 









icwl _p or t _addres s 


by 


'C0 


'b4. 


/* 


note that 


*/ 


icw2_por t_address 


by 


'c2 


'M, 


/* 


icw2 , i cw4 


.*/ 


icw4_port_address 


by 


'c2 


'b4. 


/* 

/* 

/* 


and ocw 
use same 
port addr 


*/ 

*/ 

*/ 


ocw_port_address 


by 


'c2 


'M, 



/* note: icw ==> initialization 

control 

word 

ocw ==> operational 
command 

word */ 



72 



ic wl 



by '13'b4, 



/* single PIC configuration, edge 
triggered input *7 

icw2 by '40 'b4, 

/* most significant bits of vectoring 
byte; for an interrupt 5, 
the effective address will be 
(icw2 + interrupt # ) * 4 which 
will be (40 hex + 5) * 4 = 114 hex 

*/ 

ic w4 by '0f 'b4 , 

/* automatic end of interrupt 
and buffered mode/master */ 

oc wl by '8f ' b4 ; 

/* unmask interrupt 4 (bit 4), 5:5 / 

/* interrupt 5 (bit 5), and */ 

/* interrupt 6 (bit 6), mask all others */ 

/* end 8259a codes */ 



/* include constants specific to the NI3010 
board */ 

t include 'ni3010 .del 

/* Main Body */ 

/* check message 

put skio(2) lis t( 'starting make_table ' ) ; */ 
call make_table? 

/* check message 

put skip(2) lis t ( 'make_table done'); */ 

call write_io_port( inter rupt_enable_ register, 

disable _n 1301 0_ interrupts); 
call ini tiali ze_pic ; 
call initialize_cuu_interrupts; 

call read_io_port (command_status_register ,reg_value ) ; 
call perform command (reset); 
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call program_group_addresses » 

/* assignments to the source and destination address 
fields that will not change */ 

call per f orm_command (clr_insert_source ) * 

/* NI3010 performance is enhanced in this mode */ 



unspec (block_ptr ) = block_ptr_value ; 
unspec ( r cv_ptr ) = rcv_ptr_value ; 
unspec(xmit_ptr ) = xmit_pt r_value » 

/* make one time assignments to transmit data block #/ 

t ransmi t_data_ block. destination_address_a = '03'b4J 
transmit_data_block.destination_address_b = '00'b4; 
transmi t_data_block .destination_address_c = '00'b4* 
transmit_data_block.destination_address_d = '0C'b4; 
transmit_data_block .source_address_a = '03'b4; 
transmit_data_block .source_address_b = '00'b4; 
transmit_data_block ,source_address c = '00'b4J 
transmit_data_block . source_address_d = '00'b4; 

/* get the local cluster address - file was 
opened in proc program_group_add resses */ 

get file (address) list (addr_e, addr_f)» 
transmit_data_block.source_address_ e = addr_e; 
t ransm it _da ta_bl o ck . source_addre s s^_f = addr_f; 

cluster_addr = addr e ! ! addr_f; 

put skip (2) edit CLUSTER ' , rlus te r_addr , 

Initialization Complete *** ' ) 

( col ( 15 ) , a , b4 ( 4 ) .a) ; 

i = '0001 'b4J 

call perf orm_command (go_online); 

/* at this point copy_ie_reg = RBA , but 
ie_reg on NI3010 is actually disabled */ 
call disable_cpu_interrupt s; 

do k = 1 to infinity; 

/* note: interrupt not allowed during a 
call to MCORTEX primitive */ 

erb_wri te_value = read (EP.B_WRITE) ; 

/* In the MXTRACE version”of the RTOS 
all primitive calls clear and 

set interrupts (diagnostic message 
routines), so the NI3010 interrupts 
must be disabled on entry to MXTRACE */ 
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do while (erb_write_value < i); 

/* busy waiting */ 
erb_wri te_value = read( ER3_WRITE ) ; 
copy_i e_register=receive_block_available; 
call write_io_port ( interrupt_enable_register , 

re ceive_block_ava liable ) ; 
call enable_cpu_interrupts ; 

/* if a packet has been received , thi s 
is when an interrupt may occur - can 
see that outbound packets are always 
favored. */ 

do j = 1 to 1000; 

/* interrupt window for packets received */ 
end; /* do * / 

call disable _cou_inte rrupts ; 

if (cooy_ie_register = receive_dma_done ) then 
do » 

/* receive DMA operation started, so let 
finish. */ 

call enable_cpu_interrupts J 

do while ( copy_ie_regi ster = receive_dma_done ) ; 
end ; 

call disable_cpu_interruDts » 
end; /# if t */ 

copy_ie_regi ster = disable_ni3010_interrupts ; 
call write _io_port( in te rrupt _e nab le_ register , 

disable_ni3010_interrunts) J 

end? /* busy */ 

/* ERB has an EP.P in it, so process it */ 

/* no external interrupts (RBA) until 
the ERF is consumed and the packet 
gets sent */ 

index = mod (( fixed (i ) - 1), erb_block_len ) ; 

/* 32k limit */ 

t ran s mi t_data_ block. des tinati on_address_e= 

substr(erb(index) .remote_addr, 1 ,3) * 
trans mit _dat a_block. des tinati on _add re ss_f= 

subs tr( erb ( index ) .remote_addr, 9.S) ; 

/* put overlay over ERP */ 
e_ptr = addr(erb (index) .command) ; 

call make_message; 
call advance (ERB_READ)5 

/* cauti on here ! ! ! ! 

an ADVANCE will result in a call to V?$S CKEDULER , 
which will set CPU interrupts on exit. 

It's the reason NI3010 interrupts are disabled 
first in the Do While loop above. */ 
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/* packet ready to go , so send it V 
call transmi t_packet (bytecount); 

/* cooy_ie_register=RBA, but not actual register */ 
call disable_c pu_interrupts * 

/* setting uo for next ER? consumution */ 
i = add2bi t 16( i , '0001 'b4)J 

end* /* do forever */ 

/* end main body */ 



sic#*;# / 



make_table: procedure ; 



declare 

relation file, 

( j , i ) fixed bin (15), 
eof bit (9); 

onen file (relation) stream input; 
i=0? 

eof ='0 'b4; 

do while (eof='0 'b4) ; 
i =i+l ; 

/* read data from relation.dat file ***/ 
set file (relation) edit (rel_tab( i ) .evc_id , 

rel_tab ( i ) . numdat ) 

( column (5 ) , b4( 2 ) .column ( 15) , f 1 2 ) ) 5 
do j=l to ( rel_tab ( i ) .numdat ) ; 

/* read data for all related items */ 
set file (relation) edit 

(unspec(rel_tab(i ) .data (j ) .point ) , 
rel_tab(i).data(j).alen, 
rel_tab(i).data(j). bytes) 

( column ( 25 ) ,b4( 4 ) .column (35 ) , f ( 4 ) , column (45 ) . f ( 4 ) ) ; 
max a byt es=max (maxa bytes, 

rel_tab(i).data(j). bytes* re l_tab(i).data(j).alen)*» 

end; 

/* if sentinel is reached */ 
if rel_tab ( i ) . evc_id = '00'b4 then 
do; 

eo f= '1 'b4? 

put skip list ( 'longest data queue at this cluster:', 
maxabytes,' bytes'); 

end ; 
end; 

end make table; 



/ vV J/ V" J/ ^ kC %v *** <j 

/ n' ^ x ^ ^ ^ ^ v nr ^ t nr ^r n' *np ^ ^ 
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make_mess age : procedure ; 
declare 

dat_pt r pointer , 

dat_vect ( 1500) bit (B) based (dat_ptr), 

( next_out , r , j ) fixed bin (7), 

( of f .star t , last ,k ) fixed bin (15); 

/* check for eve */ 
if erp_vect (1 )=EVC_TY?E then 
do; 

bytecount=4»* 
do k=l to 4; 

/* put eve info into data field */ 
transmi t_dat a_block.dat a( k )=erp_vect ( k ) ; 
end; 

/* check message 

put skip list transmit_data_block. data ( 1 ), ' , 

transmit_data_block.data(2) , 

transmit _data_block.dat a (3) , ' : : ", 
transmit _data_block.data(4) , ' : :: : ' ); 

*/ 

r=l ; 

/* find respective relation table entry */ 
do while ( ( rel_tab( r) . evc_id ~= erp vect(2)) & 

( rel _t ab ( r ) . evc_i d ~= '00^b4)); 

r=r+l ? 
end; 

/* if eve entry */ 
if rel_tab ( r ) . eve id ~= '00'b4 then 
do; 

/* for every related item #/ 
do j=l to rel_t ab ( r ) . numda t ; 
st art = bytecoun t i; /* find where to put ***/ 

las t = rel_tab ( r ) .data ( j ) .by tes ; /* how long it is */ 
byt ecount=bytecount + last; /* keep track */ 
da t_ptr=rel_ta b( r ) .data ( j ). point ; /*align datvect*/ 
next_out=rel_tab(r) . data( j) . next _ out; 

/* compute offset of item in data Queue */ 
of f=( rel_tab( r ) .data( j ) .bytes * next_cut) + 15 
/* compute next slot number to so */ 
rel_tab( r ) .data( j ) .next_out=mod ( next_out + 1, 

rel_tab(r).data(j).Qlen); 

do k=0 to (last-1); 

/* put item's bytes into data field */ 
transmit_data_block.data(k+start )=da t_vect ( k+o f f ) ; 
end ; 
end ; 
end? 
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/* compute total bytecount for message */ 
by tec ount=by tecount + 14; 
end; 

else doi /* if not eve */ 
end ; 

end make message; 



j ################## y 



initialize_pic : procedure; 

DECLARE 

wri te_io_port entry (bit (3) , bit(S)); 
call write_io_tiort ( icwl_port_address ,icwl ) ; 
call wri te_i o_port ( icw2_port_address , icw2 ) ; 
call wri te_i o_oort ( icw4_port_address , i cw4 ) ; 
call wri te_i o_port ( ocw_port_address , ocwl ) ; 



end initialize pic; 



jjojs # # # ?Jt # # # 3^ # # % 



perf orm_command; procedure (command); 

DECLARE 

command bit (3) . 
reg_value bit (S) , 

srf bit (S) , 

wri te_i o_port entry (bit (8) , bit (8) ), 
read_io_port entry (bit (8) , bit (8) ); 

srf = '0'b4; 

call wri te_i o_nort (command_register , command ) ; 
do while ((srf & '01'b4) = '00'b4)J 
call read_io_port ( interruot_status_reg, srf); 
end; /* do while */ 

call read_io_port (command_status_regi$ter , reg_value); 

if (reg_value > '01'b4) then 

do? 

/* not (SUCCESS or SUCCESS with Retries) */ 
put skip edit ( '*** ETHERNET Board Failure ***') 

( co 1 ( 20 ) , a ) ; 

/* when this occurs, run the diagnostic 
routine T3010/Cx, where x is the 
current cluster number */ 

s ton ; 

end; /* itd */ 



end perf orm_command ; 



/ # 5r # # # # # # # # * # 5$C # # # # S*C # ^ V ^ JjC SjC 3{55|fi # # * # # # Jr # # # # # # # 
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transmit_packet : procedure (byte count) external; 



DECLARE 

p pointer, 

byte_count fixed bin (15) , 
bytevec tor ( 2) bit (8) based (o), 
srf bit (3) , 
reg_value bit (6) , 

write_i o_port entry (bit (5), bit (8) ), 
read_io_port entry (bit (3), bit (3) ), 
enable_cpu_interruots entry, 

di sable_cpu_inte rrupts entry. 

write_bar entry (bit(16))J 

/* begin */ 
srf = '0'b4; 

call write_bar (xnit_ptr_value) ; 

/* if message longer than minimum size */ 
if (byte_count > 60) then 
do; 

p=addr (byte_count ) ; 

/* call with exact bytecount #/ 
call write _io_port( high_by te_c ount_reg,bytevector(2) ) 
call write_io_port(low_byte_count_reg,bytevector(l)); 
end ; 

/* if message is not longer than minimum size */ 
else do? 

/* call with minimum bytecount of 60 */ 
call write_io_port(high_byte_count_reg, '33 'b4) ; 
call write_io uort ( low_byte_count_reg , '3c 'b4 ) * 
end; 

couy_ie_regist er = t ransmi t_dma_done ; 

call write_io_port(interrupt_enable_ register, 

t ransmi t_dma_done ) ; 
call enable_cpu_i nte rrupts ; 

do while ( copy_ie_register = transmi t_dma_done ) ♦ 
end; /* loop until the interrupt handler 
takes care of the TDD interrupt - 
it sets copy_ie_regis ter = RBA */ 
call perf orm_command ( load_and_send ) ; 
put skip li st ( 'transmitting' ) ; 
end transmit_packet J 

/*#*######### ********* *********** ****#********#*******X* 
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HL_interrupt _handler : procedure external; 

/* This routine is called from the low level 
8086 assembly language interrupt routine */ 

DECLARE 

write io_port entry (bit (8), bit (8) ), 
read_Io_Dort entry (bit (8) , bit (8) ), 
enable_cpu_interrupts entry, 

disable_cpu_ir.ter ruots entry, 

write_bar entry (bit(16)); 

/* begin */ 

call write _io_oort( in terrup t_enable_regi st er , 

disable_ni3010_interrupts); 

if ( copy_i e_regi st er = receive_block_available ) then 
do ; 

call write_bar ( rcv_ptr_value) ; 

call wri te_i o_por t (high_byte_count_reg, ' 05 'b4 ) ; 

call wri te_io_port( low_byte_count_reg, 'f2'b4) ; 

/* initiate receive DMA * / 

copy_ie register = receive_dma_done ; 

call write_io_port ( interruDt_enabl e_regi st er , 

receive dma done)* 



end; /* do */ 
else 

if (copy_ie_register = recei ve_dma_done ) then 
do; 

call process_packet ; 

cop.y_ie_register = recei ve_block_a vai lable * 
call wri te_io_port ( interrupt _enable_regi s ter , 

receive_block_available) ; 
end? /* if then do */ 
else 

if ( copy_ie_regi st er = transmi t_dma_done ) then 
do; 

c opy_ie_regis ter = receive_blo ck_avai lable ; 

/* NI3010 interrupts disabled on entry '*/ 
end; /* if then do */ 

end HL_interrupt_handler! 

1 i Vf 'V *it ^ ^ nU vV ^ ^ ^ ^ ^ *** ^ ^ y# J# / 

/ o' Or Or o' o' nr o' o^ or " •'r o' nr o % or or no o' or o' o' # r o** o' or or or or o* # r o' o v or or or <^r ^r or ^r # r o % ^r # r / 
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process_packet : procedure? 

DECLARE 

evcid tit (S) , 
local_evc_value tit (16), 

(dat_ptr,p) Dointer, 

remote_ev c_value tit (16) tased (p), 

dat_vect ( 1500 ) tit (8) tased (dat_ptr), 

( of f , star t , last , k) fixed tin (15), 

(next_in , r , j ) fixed tin (7); 
put skip list ( 'receivi ng ' ) ? 

/* check for eve */ 

if receive_data_tlock.data (1 )=evc_type then 
do? 

p = addr ( recei ve_dat a_tlock . data ( 3) ) ? 
evcid=receive_dat a _block.dat a (2) ? 
local_evc_value = read(evcid)? 
if 1 ocal_evc_value < remote_evc value then 
do * 
r=l? 

/* find eve entry in relation tatle */ 
do while ( ( rel_tat ( r ) .evc_i d ~= evcid) & 

( rel_tat ( r ) . evc_id ~= '00' t4))? 

r= r+l ; 
end ? 

if rel_tab( r ) .evc_id ~= '00 'b4 then 
do ? 

tytecount=4? /* jump over eve info */ 

do j=l to rel_tat( r ) .numiat i 

start=bytecount+l ; /* compute start of item */ 

last=rel_tab ( r ) .data ( j ) .by tes » /* and length */ 
by tec oun t=byte oount+las t ; /# and item's end ~/ 

next_in=rel_tab(r) .data ( j ) .next_in? 

/* compute offset in data aueue */ 
of f = ( las t^next _in ) + 1? 

/* compute next slot number to fill */ 
rel_tab(r).data(j) . next_in=mod ' next_in+l , 

rel_tat( r) .data ( j ) .alen) ? 

da t_D tr=rel_ta b ( r ) . da ta ( j ) . po int ? /* align datvect*/ 

do k=0 to (last-1)? 

/* put item bytes into data aueue */ 
dat_vect (k+off)=receive_data_block.data(k+start) » 
end ; 
end; 
end ? 
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/* update local eve value V 
do while ( 1 ocal_ev c_value < remote_evc_value ) ; 

call advance (evcid); 

local_ev c_value = add2hi tl6 ( local_evc_va lue , '<2221 'b4) * 
end ; 
end* 

else do? /* if not eve */ 
end; 

call iisable_c pu_i nt errupts ; 
end ; 

end process_packet ; 






program_group_addresses : orocedure ; 



DECLARE 



1 group_addr(40) based (group_ptr) 



2 


nc_grouo_f ield 


a 


bit 


(8), 


2 


mc_group_f i eld 


_b 


bit 


(8), 


2 


mc_g rouo_f i eld 


c 


bit 


(8), 


2 


mc_group_f ield 


Id 


bit 


(8), 


2 


mc_group_field 


e 


bit 


(3) , 


2 


mc_group_f ield 


_f 


bit 


(a); 



DECLARE 

( group_pt r , p ) pointer, 

( f ield_e , field_f) bit (8). 
bit_3_groups bit (8) based (p), 

(i ,num_groups .groups_times_6~) fixed bin (7); 

ur.soec(group_ptr) = xmit_ptr_value; 
open file (address) stream input; 
get file (address) list ( num_groups ) ; 
do i = 1 to num_groups 5 

group_addr ( i ) ,mc_group_f ield_a = '03'b45 
gr oup_addr ( i ) . mc_group_f ield_b = '00'b4J 
gr oun_addr ( i ) . mc_group_f ield_c = '00'b4; 
group_addr ( i ) ,mc_group_f ield_d = '00'b4J 
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get file (address) list ( field_e, field_f ) ; 
groun_addr( i ) .mc_£rroun_f ield_ e = field^el 
group_addr( i ) .mc_group_f ield~f = field_f; 

end; /* do i */ 

call disable_cpu_interrunts ; 

call write_bar ( xmit_ptr_value ) 5 

call wri te_io _ po r t ( high_byte_ c oun t_reg , '00' M); 

groups_times_6 = 6 * num croups; 

p = addr (groups_times _6T? 

call write_io_port( 1 ow_by te_count_reg , bi t_8_groups ) ; 

cony_ie_regis ter = t ransmi t_dma_done ; 

call wri te_io_po rt ( i nterrupt_enable. register, 

transmit_dma_done) ; 
call enable_cpu_interrunts ; 

do while ( copy_ie_register = transmi t_dma_dor.e ) ; 
end; /* loop until the interrupt handle” 
takes care of the TDD interrupt - 
it sets C0?Y_ IE_REG = R3A */ 

call perf orm_command ( 1 oad_eroup_addre sses ) ; 



end prosram_group_eddresses * 



end; /* system device handler and packet processor 
(driver) */ 



>V Of Of Of Of j/ Of ^ V* %V %V *V 'V V/ ^ ^ Of ^ O# J/ V 4 Of ^ Of Of y# %*# %•# y * %'# %lf 

ff* -np ^ ^ fj+ #p #,« rj% ^ ^ ^ *p #p <>p #p ^p 

sic########;):# j;c £ 3JC j.-s## # 3 ;:# sjc # 






ASMR00T.A86 file 



-p 



^ ^ O# %*# Of *V s 1 * Of %if Of Of Of Of s % + Of %V *V# J# %*4 > f * 'V 'V ^ J# ^ Of Of Of Of Of Of Of Of Of Of Of Of Of Of Of Of O# V* Of Of Of Of 

/p rp ff> «*p /p #p #p #P #|% #p #P >p / % ^p #P #p #p #P /||^ /p ^P ^|* #P ^p /p #p #p #|- ^ rp ^ # 4 ’» /p #p "P rp ^ #p #P /p /p #P 



extrn hl_i nte rrupt_ handler : far 

Dubl ic wri te_io_ port 
public read_io_port 
public write_bar 

public ini t iali ze_cpu_ interrupt s 
public enable_cpu_interrupts 
public disable_cpu_interrupts 

J ^CJj» 3}C 3}C ?JS 3*S JjC 3jS >[« 5{C J}C 5{t 3j( ^ 3jC V 3{C Jjt 3{S 5jC j}S ?}C 5jC J{t 5j» ^ ^ 2{i 3}? »[» Jj* 3*5 5(£ 5{i 3jt Sjt 5^C 3{S 5(s 3p 3jC 5^5 3{i IjC 3p 3jC J{C j){ JfT 3j* ^ 
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exit 



vrite_io_port : 

; Parameter Passing Specification: 
♦ entry 



; parameter 1 

f 

I parameter 2 



<port address> 



< unchangei> 



<value to be outputted> <unchar:ged> 



dseg 


port 


_add 


ress rb 1 


csea 


push 


bx ! 


push s i ! nush 


mo v 


si , 


[bx] 


mov 


al. 


[si] 


mov 


por 


t_address, al 


mov 


si , 


2 [bx] 


mov 


al. 


[si] 


mov 


il. 


oort address 


mov 


4h, 


00h 


out 


dx , 


al 


pop < 
ret 


ax ! 


pop dx ! poo si 









read_i o_port : 



Parameter Passing Specification 







entry 


exit 


naramet er 


1 


<nort address> 


<unchanged> 


parameter 


2 


<meaningless> 


<register value 



cseg 



push 


bx ! 


push si! nush dx ! push ax 


mov 


si , 


[bx] 


mov 


al , 


[si] 


mov 


port 


address, al 


mov 


si , 


2 [bx] 


mov 


dl, 


port address 


mov 


dh , 


00h 


in 


al, 


dx 


mov 


[si] 


, al 


POD 

ret 


ax ! 


pon dx! pop si! nop bx! 
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write tar: 



Parameter Passing Specification 

parameter 1 (and only): tbe address of the data bloc* 

to be transmitted or received. 



dseg 






e_bar_port 


ea u 


0b9h 


h_bar_port 


eau 


0bah 


l_bar_port 


equ 


0 bbh 


temp_e_byte 


rb 


1 


temp_es rw 


1 




cseg 







* This module commutes a 24 bit address from a 32 bit 
» address - actually it's a combination of the PS 
» register and the IP passed via a parameter list- 

push bx ! push ax! push cx ! t>ush es ! push dx ! push si 



add_l : 
no add: 



mov dx, 0800h 5 shared memory segment 

mov es , dx 

mov temp_es , es 

mov dx, es 

mov si, [bxl 

mov ax, [sil 

mov cl , 12 

shr dx, cl 

mov temn_e_byte, dl 

mov dx, temp_es 

mov cl, 4 

shl dx, cl 

add ax , dx 

jno no_add 

inc temp_e_byte 

out l_ba r_oort , al 

mov al , ah 

out h_bar_port, al 

mov al , temp_e_byte 

out e_bar_port , al 

pop si! pop dx ! pop es! pop cx ! pop ax! pop bx 
ret 



• ########## #3$: ############*## a*######### 
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initialize cpu interrupts 



? Module Interface Specification: 

; Caller: Ethertes t ( PL/I ) Procedure 

; Parameters: NONE 



initmodule cseg common 
ots 114h 

int5_offset rw 1 
i nt5_se ^rment rw 1 

cse? 

push bx 
push ax 

mov bx , offset interrupt_handler 

mov ax, 0 

push ds 

mov ds , ax 

mov ds : int5_of f set , bx 

mov bx . cs 

mov ds :int5_se£men t , bx 

pop ds 

pop ax 

pop bx 

sti 

ret 



• ### ###### ## ijssjs #3}! 



enable_cpu_in terrupt s : 

i on : 

t ( PL/I ) Procedure 

Parameters: NONE 



Module 


Interface 


Snecificat 


Ca 


Her : 


Ether tes 



sti 

ret 






86 



disable_cpu_i nterrupts : 



; Module Interface Specification: 

; Caller: Ether tes t ( PL/I ) Procedure 

* Parameters: none 

cli 

ret 



inte rrupt_handler : 



; IP, CS, and flags are already on stack 
; save all other registers 

push ax 
push bx 
push cx 
push dx 
push si 
push di 
push bp 
push ds 
push es 

call hl_interrupt_handler 

i high level source routine 
i In Ethertest Module (PL/I) 

; restore registers 



pop es 
pop ds 
pop bp 
pop di 
pop si 
poo dx 
po p cx 
Pod bx 
pop ax 
st i 
iret 



end 

• a;:###### ***£:$*#*## 
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* GATEMOD / GATETRC File GATEM /T . aS6 BREWER 1 SEP 84 */ 

# -* / 

*5* Thi<; mndul p i <; ?1 vpr t.n t.hp mpr in nh i fnrm t.n 1 i nlr # / 

*/ 
*/ 
*/ 
*/ 

*/ 
*/ 
7 
-*/ 
*/ 
*/ 
*/ 
-*/ 
7 
■*/ 
7 

The ADD2BIT16 function does not make calls to MCORTEX. ***/ 
It's purpose is to allow the addition of two unsigned */ 
16 bit numbers from PL/I programs. */ 

- *V* 'i- *>' j 



: Thi s 


mo 


dule is given to 


the user 


in obj form to 


1 


ink 


; with 


hi 


s initial and process modules. Any 


cha n 


ge 


s to 


user 


se 


rvices available 


from the 


OS must be 


ref 


le 


cted 


: here 


• 


In this way the user need 


not be con 


cern 


ed 


wi th 


; actual 


GATEKEEPER servic 


es codes. 


Two line 


s of 


c 


ode 


are 


con 


tai ned in cond i t i 


onal asse 


mbly state 


men t 


s 


and 


O 

o 

•a 


rol 


the output to be 


GATEMOD 


or GATETRC 


depending 


; on the 


value of GATEMOD 


at the code start. 








This 


mo 


dule reconciles parameter 


passing an 


omal 


ie 


s 


between 


MCORTEX (written 


in PL/M) 


and user 


prog 


rams 


( wr i 


tte 


n in PL/I ) . 












All 


cal 


Is are made to the GATEKEEPEP in LEV 


EL2 


of 


the 


OS. 


Th 


e address of the 


GATEKEEPER must be 


give 


n 


bel ow . 



❖ 

Ju 
*Y* 

❖ 

❖ 

❖ 

❖ 

# 
o> 

* 

3fc 
❖ 

# 

3*r 

# # 3{< 3j< # 3j< # 3£ 3{C 3* 3£ 3^ 3jC 3£ # SjC # 3*C # # # # # # # 3{C # # # 3^ # # # 3£ # # Sfc # # # # # # # # # # 3 * # 3* 3 



DSEG 



GATEMOD SOU 3 ;*#* SET TO ZERO FOR GATETRC 
?*** SET TO ONF FOP. GATEMOD 
PUBLIC ADVANCE ;*** THESE DECLARATIONS MAKE THE 

PUBLIC AWAIT ;*** GATEKEEPER FUNCTIONS VISI3LE 

PUBLIC CREATE_EV C ;*** TO EXTERNAL PROCESSES 
PUBLIC CREATE_PROC 
PUBLIC CREATE SEO 
PUBLIC PREEMPT 
PUBLIC READ 
PUBLIC TICKET 
PUBLIC DEFI NE_CLUS TER 
PUBLIC DI STRI BUTION_MAP 
PUBLIC ADD2BIT16 



AWAIT_IND ECU 3 
ADVANCE_IND ECU 1 
CREATE EVC_IND EOU 2 
CREATE SEO IND ECU 3 



I*** THESE APE THE IDENTIFICATION 
;**# CODES RECOGNIZED BY THE 
?*** GATEKEEPER IN LEVEL II OF 
;*** MCORTEX 



TICKET_IND EOU 4 
READ_I ND EOU 5 
CREATE_PROC_I ND EOU 6 
PREEMPT_IND EOU 7 
DEFI NE_CLUS TER_I ND EOU 9 
DISTRIBUTION MAP IND ECU 9 
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IF GATEMOD 

GATEKESPSR_IP DW 0036H 
GATEKEEPER_CS DW 0BADH 
ELSE 

GATEKEEPER_IP DW 0068E ;#### I #### < 
G ATEKEEPEP._CS DW 0B4CH ; #### 2 ttnnu < 
ENDIF 

GATEKEEPER EOU DWORD PTR GATSK EEPER_I P 
CS EG 



; # AWAIT AWAIT *** AWAIT AWAIT ’*** AWAIT ********/ 

AWAIT: 



PUSH ES 
MOV SI,2[BX] 

MOV BX, [BX] 

MOV AL , AWAI T_I ND 
PUSH AX 
MOV AL, [BX] 

PUSH AX 
MOV AX, [SI] 

PUSH AX 
PUSH AX 
PUSH AX 

CALLF GATEKEEPER 
POP ES 



; S I <-- PNT TO COUNT AWAITED 
;BX <-- PNT TO NAME OF EVENT 

;N <— AWAIT. INDICATOR 

* BYT < — NAME OF EVENT 
JAX <-- COUNT AWAITED 
; WORDS <-- COUNT AWAITED 
;PTR_SEG UNUSED WORD 
I PTR OFFSET <— UNUSED WORD 



RET 



;*** ADVANCE *** ADVANCE *** ADVANCE 



3 ^ A D V A N C 53 *** ^ ^ *** ^ *** / 



ADVANCE: 



PUSH ES 
MOV BX, [BX] 

MOV AL , ADVANCE_I ND 
PUSH AX 
MOV AL, [BX] 

PUSH AX 
PUSH AX 
PUSE AX 
PUSH AX 

CALLF GATEKEEPER 
POP ES 



5BX <-- PTR TO NAME OF EVENT 

;N <— ADVANCE INDICAT2R 

JBYT <-- NAME OF EVENT 
JWORDS <— UNUSED WORD 
» PTR_S EG <-- UNUSED WORD 
JPTR OFFSET < — UNUSED WORD 



RET 
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; *** CREATE EVC *** CREATE EVC *** CREATE EVC *************/ 



CREATE EVC: 



PUSH ES 
MOV BX, [BX] 

MOV AL,CREATE_EVC_IND 
PUSH AX 
MOV AL.CBX] 

PUSH AX 
PUSH AX 
PUSH AX 
PUSH AX 

CALLF GATEKEEPER 
POP ES 



;BX <-- PTR TO NAME O-F EVENT 

*,N <— CREATE_EVC INDICATOR 

;BYT <-- NAME OF EVENT 
{WORDS <— UNUSED WORD 
;PTR_SEG < — UNUSED WORD 
{ PTR OFFSET < — UNUSED WORD 



RET 



{#** CREATE SEQ *** CREATE SEO *** CREATE SEO #*###*###*##*/ 



CREA TE_SEO : 

PUSH ES 
MOV BX, [BX] 

MOV AL . CRE ATE_SEO_IND 
PUSH AX 
MOV AL, [BX] 

PUSH AX 
PUSH AX 
PUSH AX 
PUSH AX 

CALLF GATEKEEPER 
POP ES 



RET 



;*** TICKET *** TICKET *** TICKET *** TICKET *** TICKET ***/ 
TICKET: 



JBX <— PTR TO NAME OF SEO 

JN <— CREATE_S EO INDICATER 

{BYT <— NAME OF SEO 
{WORDS <-- UNUSED WORD 
{ PTR_SEG <— UNUSED WORD 
{PTR OFFSET <— UNUSED WORD 



PUSH ES 
PUSH ES 
MOV CX,SP 
MOV BX, [BX] 

MOV AL , TI CKET_I ND 
PUSH AX 
MOV AL, [3X] 

PUSH AX 
PUSH AX 
PUSH SS 
PUSH CX 



{TICKET NUMBER DUMMY STORAGE 
{POINTER TO TICKET NUMBER 
; BX <— PTR TO TICKET NAME 

?N <— TICKET INDICATER 

{BYT < — TICKET NAME 
{WORDS <— UNUSED WORD 
{ PTR_SEG A— TICKET NUMBER SEG 
{ PTR OFFSET <— TICKET NUMBER POINTER 
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CALLF GATEKEEPER 
POP BX 
POP ES 



jretrieve ticket number 



RET 



;*** READ *** READ *** READ *** RE. 8 D #*# PEAD *** READ ****/ 



READ: 



PUSH ES 
PUSH ES 
MOV CX,S? 

MOV BX . [3X1 
MOV AL , READ_I ND 
PUSH AX 
MOV AL , [BX] 

PUSH AX 
PUSH AX 
PUSH SS 
PUSH CX 

CALLF GATEKEEPER 
POP BX 
POP ES 



;event count dummy storage 

J POI N TER TO EVENT COUNT 
;BX <-- PTR TO EVENT NAME 

JN <— READ INDICAT SR 

5 3YT <— EVANT NAME 

JBYT <— UNUSED WORD 

;PTR_S3G < — EVENT COUNT SEGMENT 

;PTR_OFFSET <--EVENT COUNT POINTER 

JRETRIEVE EVENT COUNT 



RET 



;*** CREATE PROC *** CREATE PROC *** CREATE PROC 



V# ' > / 

#1% ^ / 



CREATE PROC: 



PUSH ES 
MOV S I , 14 [BX] 



PUSH WOPD PTR 
MOV SI , 12 [BX] 



PUSH WORD PTR 
MOV S I 4 10[BXl 
PUSH WORD PTR 
MOV SI, 3 [BX] 
PUSH WORD PTR 
MOV SI , 6TBX] 
PUSH WORD PTR 
MOV SI , 4 [3Xl 



PUSH WORD PTR 
MOV S I , 2 [BX] 
MOV AH, [SI' 
MOV SI , [BX 



MOV AL, 
PUSH AX 



[SI] 



MOV CX,S? 

MOV AL, CREATE 





; S I <-- PTR TO 


PROCESS 


ES 


[SI] 


;STACK PPOCESS 


ES 






;si <-- PTR TO 


PROCESS 


DS 


[SI] 


JSTACK PROCESS 


DS 






; S I <-- PTR TO 


PROCESS 


CS 


[SI] 


JSTACK PROCESS 


CS 






JSI <— PTR TC 


PROCESS 


I? 


[SI] 


JSTACK PPOCESS 


IP 






JSI <~ PTR TO 


PROCESS 


SS 


[SI] 


JSTACK PROCESS 


SS 






JSI <-- PTR TC 


PROCESS 


S? 


[SI] 


JSTACK PROCESS 


S? 






JSI <-- PTR TO 


PROCESS 


PRIORIT 




JGET PROCESS ?: 


RIORITY 






JSI <-- PTR TO 


PROCESS 


ID 



JGET PROCESS ID 

JSTACK PROCESS PRIORITY AND ID 
* PO I N TER TO DATA 

PROC IND 
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PUSH AX 
PUSH AX 
PUSH AX 
PUSH SS 
PUSH CX 

CALLF GATEKEEPER 
ADD SP.14 
POP ES 



JN <-- CREATE PROCESS IND 
JBYT < — UNUSED WORD 
JWORDS <— UNUSED WORD 
;PROC_PTR SEGMENT < — STACK SEG 
5PROC_PTR OFFSET < — DATA POINTER 

J REMOVE STACKED DATA 



RET 



PREEMPT PREEMPT PREEMPT *** PREEMPT / 

PREEMPT: 



PUSH ES 
MOV BX, [BX] 

MOV AL,?RESMPT_IND 
PUSH AX 
MOV AL. [BX] 

PUSH AX 
PUSH AX 
PUSH AX 



5BX <-- PTE TO NAME OF PROCESS 

;N < — PREEMPT INDI CATER 

JBYTE < — PREEMPT PROCESS NAME 
JWORDS <-- UNUSED WORD 
JPTR SEG <-- UNUSED WORD 



PUSH AX JPTR OFFSET <— UNUSED WORD 

CALLF GATEKEEPER 
POP ES 



RET 






DEFINE CLUSTER *** 



DEFINE CLUSTER 



**/ 



DEFINE CLUSTER: 



PUSH ES 



MOV BX, [BX] J BX <— PTR TO LOCALS CLUSTER SAD DR 

MOV AL, DEFI NE_CLUS TFR_I ND 

PUSH AX JN < — DEFINE CLUSTZR_I ND 

PUSH AX JBYT <-- UNUSED WORD 



PUSH WORD PTR [BX] 
PUSH AX 
PUSH AX 

CALLF GATEKEEPER 

POP ES 

RET 



JWORDS <— LOC ALSCLUSTEHSADDR 
JPTR_SEG <-- UNUSED WORD 
JPTR OFFSET <— UNUSED WORD 
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DISTRIBUTION MAP *** D ISTRI BUTON MAP **# *#/ 



DIST 


RI BUT I ON_MAP : 




PUSH 


ES 






MOV 


SI , 


*[BX] 


; S I <— PTR TO GROUP ADDRESS 


PUSH 


WORD 


) PTR [SI] 


; STACK THE GROUP ADDRESS 


MOV 


SI, 


2 [BX] 


JSI <— PTR TO ID OF MA?_TY?E 


MOV 


AH, 


[SI] 




MOV 


SI, 


[BX] 


;SI <-- PTR TO MAP TYPE 


MOV 


AL, 


[SI] 


;AL <-- MAP TYPE 


PUSH 


AX 




; STACK ID AND MAP TYPE 


MOV 


CX, 


SP 


J POINTER TO DATA 


MOV 


AL, 


DISTRIBUTION 


MAP IND 


PUSH 


AX 




JN <— DISTF.IB MAP IND 


PUSH 


AX 




JBYT < — UNUSED WORD 


PUSH 


AX 




* WORD <— UNUSED WORD 


PUSH 


SS 




;MAP PTR SEG <— SS 


PUSH 


CX 




JMAP PTR OFFSET < — DATA PTR 


CALLF GATEKEEPER 




ADD 


SP, 


4 




POP 


ES 






RET 









;*** ADD2BIT16 *** ADD2BIT16 



ADD2BIT16: 






MOV SI , [BX] 


JSI 


<— 


MOV BX , 2 [BX] 


; bx 


<— 


MOV BX , [BX] 


;bx 


<— 


ADD BX.fSIl 


;bx 


<-- 



** ADD2BIT16 *** ADD2BIT16 **/ 



PTP. TO 3IT(16)#1 
PTR TO BIT(16)#2 
B IT ( 1 6 ) #2 

3 IT ( 1 6 ) #1 + 3IT(16)*2 



RET 



END 






X *: # at # * # at # # j* # # #. * * <; v # 
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APPENDIX E 



THE DEMONSTRATION PROGRAM 

The demonstration program is a combination of four 
modules that simulate gathering and processing track 
information and calculating direction and launcher number 
for missile launchers. 

It was not a goal of this demonstration program to 
provide a valid algorithm for a real system, but rather to 
show the synchronization of distributed asynchronous 
processes with different execution times, working with 
different length shared data queues, that reside at 
different addresses at different clusters. Another goal was 
to demonstrate the systems ability for processes working in 
shared buffers, or with local copies of shared data items, 
or a combination of both. 

Process trkdetec simulates the track detection by 
producing x, y, and z track data. The track information is 
put into the 50 slot queue TRACK. 

Process trkrprt simulates the track movement calculation 
by producing dx, dy, and dz values from the comparison of 
two consecutive track informations. It consumes TRACK data 
and puts delta information into the 20 slot queue DELTA. 

Process mslorder simulates the missile launcher 
direction calculation. It consumes TRACK data and DELTA data 
and combines these into simulated azimuth and elevation 
information and assigns a launcher. These data are put into 
the 50 slot queue MISSILE_ORDER . 

Process msltrain simulates the missile launcher training 
by consuming MISSILE_ORDER data and displaying launcher 
number, launch number, azimuth, and elevation. 

For demonstration purposes each process displays its 
calculated values and its status (e.g. waiting, going, done, 
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queue full, etc.) 

The program was successfully run in three different 
constellations : 

1. ) Process trkdetec and process msltrain multiplexed on 
one SBC, and process trkrprt and process mslorder 
multiplexed on a second SBC in the same cluster (cluster 2). 

2. ) Process trkdetec and process msltrain multiplexed on 
one SBC in cluster 1, and process trkrprt and process 
mslorder multiplexed on one SBC in cluster 2. 

3. ) Process trkdetec on one SBC and process msltrain on 
another SBC in cluster 1, and process trkrprt on one SBC and 
process mslorder on another SBC in cluster 2. 

The Link86 Input option was used to link cluinit, 
trkdetec, msltrain, and gatemod into C1USERS; c2uinit, 
trkrprt, mslorder, and gatemod into C2USERS for 
constellation 1.) and 2.). 

For constellation 3.) following linkage was done: 

trkdinit, trkdetec, and gatemod into TRACKER, 
msltinit, msltrain, and gatemod into MSLREACT , 
trkrinit, trkrprt , and gatemod into REPORTER, and 
msloinit, mslorder, and gatemod into MSLORD. 

This demonstration program, even though done by one 
person, was built under a simulated lead programmer team 
policy. The lead programmer provided the system-wide shared 
data declaration, the system definitions, the cluster 
specific relation data, pointer assignments, and systems 
initialization. The lead programmer also decided about the 
distribution of the different modules over the system. 

The application programmers built their modules 
%including the share. del and pointer. ass files. 
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#### #######:£# 5^5{c jJC3^3^^53jC3jC^C^C^C^6a^X«3jC?!«5}t3^54C>>t^a{e34C3fiK 5jS^?3^3^3^5^>{:^C5^^5^5^5^S^3^3^3^?}CS{C3tC3^3je3jC 



*** Cl USERS . IN? file *** 

###_ _ __ #3$C 3£ 

*** This file is used to link user initialization, *** 

*** user process msltrain, user process trkdetec, and *** 

*** gatemodule into C1USERS.CMD, the executable file *** 
multiplexing the two user processes on one SBC. **# 

sfc sj: :}: 3jc # # 3js ?Jc # sjs s£ sis 3{e # sje 5|s s£ 5ji s$c :jc 5J: s£ # sfc # # s}: j{c # ^ojs 3|s # # # ;J: # # sje 3js # 3jc s£ sfc 3{c s£ # # s£ 3|c $ s}s # 3J: # ^ # # 



clusers = 

cluini t [code [a b [439]] ,da ta [ab [800] ,m [0] , ad [82] ] , map [al ll ] , 

trkdetec , 

msltrain, 

gatemod 






*** C1UINIT.PLI file *** 

_______________ ____. — __ _3£#S}? 



*** This is the initialization procedure for the #** 

*** multiplexed user constellation. *** 

3^^C3^3ji3^^3^ ## # ## # 5^C 3jC # 3* # 3£# ## # # # 3^3jC # 3* 5$C 3jJ 3^3£ # 3£# 3£ S£ S£ # 3*3? 3£ 3}C 3£ # 3jS 



cl_users_ini t : procedure options (main); 

%include 'sysdef .pli ' ; 



/* begin */ 



call 



/* trkdetec #/ 

create_proc ('05'b4, 'fc'b4, 

'09eb'b4, '0800 'b4, 

'0439'b4, '0800 'b4. 



'0029 'b4 , 
'0800 'b4 ) J 



/* msltrain */ 

call create_proc ('06'b4, 'fc'b4, 

'0a0b'b4, '0800 'b4 , 
'0439 'b4, '0800 'b4, 
call await {'fe'b4, '01'b4)» 
end cl users ir.it* 



'0205 'b4 , 
'0800 'b4) ; 



# # 3{c # 3fc 3{: 3£ # # 3{C 3$: 3^ # # 3jC # 3JC # # # # # # 3^ # # # 3$: 3js # # #>{« 3}s 3}S # 3jC 3* # # 3£ 3{C 3{C 3jc Sj? 3^ Sjfi 3{C # 3^ 3{c 3jC 3jC # 3jC 3J: 3^ 3^ 3* 3{C 
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$$###$$;: $»;»(< sjojc####### ### ;;<:)c###>}c#3*c:(t *##### ########### 5}:# ########## 

*** TRACKER. I NP file *** 

### 

*** This file is used to link trkietec initialization, *** 
*** user process trkdetec, and gatemodule into- *** 

*** TRACKER.CMD, the executable file for user process *** 
*** trkdetec in the non-mult iplexed constellation. *** 



tracker = 

trkdinit [code [ab[439]] ,data [ab[800] ,m[0] ,ad [82]] ,map[all] ] , 

trkdetec , 

gatemod 



Xc# # # # # & j[c # ijc # # ####$### h;:##:;:#####:;;# ####### a*#### # ######## 

* ajc * # i £ # sjc # # # * # # # # * £ 5fie # 5jc # # # # # 5jc pjc # # # # # # # # # # # # # # # # # # ajc # ^ # * # # # # # # # # # # 



*** TRKDINIT. PLI file 

❖#* 



*r '!' *»' 



*** This is the initialization procedure for user *** 

*** process trkdetec in the non-mul ti plexed *** 

*** constellation. *** 

# # # # ;$: # # ajc >J; # # # $ # # : £ # # # # # # # # # # # # # # # # # ajc # # # # # # # # # # # # # # ajs # # # # # s£ # # a£ # 



*V ^ ^ %U <*V *V *V ^ %V >V *•* V* ^ *V v* ^ O# %V Vp **/ >V %V >V *-V *V vV »•# %•# *v ^ ,# 

^ * 4 - #(% *4* #1% *(+ #> ' /j^ #f» # ^ ^ r/% #4% ^ ^ ^ ?jS ^ ?p ^ ^ ^ "T V ^T HT *1* 'P V *P # P *T* *Y* T ^P V ^P V +f ^p ^P ^P 



trkdinit: procedure options (main)* 

^include 'sysdef .pli ' ; 



/* begin */ 

call create_proc ('01'b4, 'fc'b4, 

'085d'b4, '0800'b4, '0023'b4, 

'0439'b4, '0800'b4, r 0800'b4); 

call await ('fe'b4, '31'b4); 



end trkdinit* 



# # 5^ * ^ 3^ 3^ 5}C # 3}t ^C 3jC # 5^ 3{: 5^ # ^ ^ ^ 2^ # ❖ ^ ^ ^ ^ ^ ^ 3^ # >>! ?}: 5^ 5^ # 3^ 3^ Xr # >}C XC >|< ^ ^ 5^ 5^ # ^ >,< ^ # 

5^>^5jc>lc 3{< 5*C 5^ >ic 5^ b}< 3}: 5^ b’.O^ 5^ 3(C 5^ # # ;’,i # # # # 5^ 3$C ^ 



;! '-* MSLREACT.INP file 





*** This file is used to link msltrain initialization, 

*** user Drocess msltrain, and gatemodule into 

MSLREACT.CMD, the executable file for user process 
msltrain in the non-multiplexed constellation. 

ou **u «ju %v %v «4^ ju >v <ju j# «»v %v %v %v v 1 # %*# %v O/ j^ %*# %v -sV sV %v %v >v %v# «v v*# %•# %*# 

■ — - - - -- ^ « |*a <Y* «P # 1 % «|« /p #p #p #|« rp #p ^p <Y* ^p Zp >P rp ^P *qp ^ **p ^p #p ^ #|% Up /p ^p #p **p pp ^P ^P #P #lP /p fp #p # 4 -* #p #P ^p #p #p #P ^P 



«T» #p #p #p - 



mslreact = 

msltinit [code[ab[439]] ,data[ab[800] ,m[0] ,ad[82]l t man[allll . 
msltrain , 
ga temod 
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5JC # 3JC # # # # # 5JC # # # # # 5$S # 5}: # J$C # # # # # # 3£ # # # # # # # # # # 5£ # # # # # # # # # 3}: # # 5* # # SJC # # # # # # 



*** t*SLTIN IT . PLI file *** 

❖ 5? St — — — St St s: 

«stst This is the initialization procedure for user *** 

*** process msltrain in the non-mul tiplexed *** 

*** constellation. *** 






5j< $ sjs ^s # ^ # sj: # >;< # # # sj< # # # # >£ # $ # ?;< # ;Jc # # 3{« # # # 3$e j|c # # # 5js sfc # # # # # # # # t|< sgc##^ ##$$#; 



msltinit: procedure options (main)* 

%include 'sysdef .pli ' ; 



/st begin */ 

call create_proc ('02'b4, 'fc'b4, 

'0825'b4, '0600'b4, '0023'b4, 
'0439'b4, ' 0800 'b4 , '0300'b4); 
call await ('fe'b4, '01'b4); 
end msltinit? 



£ £ # # # $ # # # # 3? # # # 3}C # # # # # # # # # # # 5jC # # # # # # # # # # # 5jc # # # # # # # # # # # # # # # # # # # # # 

%u %»# sV# %♦# O# \i> Oi* %•/ %}+ %i/ % f # %i/ y* *v V# V* V# *iV ^ %V %V V# *V **V *iV +>+ >V •*# %V *** '•> s*^ %U 

<v* ^ ^ #|^ rp ^ >|\ *|"* ^|S /y' *ip ^p /p ^ nr nr* +% % +% % *{* <p *,% #p ^p 

*** TP.KDETEC . PLI file R. Haeger, Dec 1985 slJ5i:!i! 

St st st ststst 



stst* This is the PL/I-96 code for user process tr.-cdetec. *** 
ststst it simulates track detection by incrementing track *#* 
*** position values every iteration. It produces shaded *** 
*** data TRACK. *** 

j*?>^^c^C3^3;t^5{s^;3^ ^?3^5^s^^:3^^i3^^:^5^5^3p^c5^;J:5;<^c5{s^c5^^^c^t^c^c^3^ 5^3}:3^>jc 
s;c 5j:^< ^ 5^ # 3}J 5 ;: 3^ ## 3|C 5 ^ 3 ;; 5^?;< 5^5^; J*C# 5^^^ 3{C # ^ SiOjC^S ## 3^ 3je 3^ # # 3£3£# 3^ 3^ 



trkdetect: procedure ? 

%reulace 



infinity 


by 


32767, 


one 


by 


'0001 'b4. 


to len 


by 


50 ; 



%include 'sysdef . pli ' ; 

%include 'share. del'; 

/* used shared data: 

1 track(0:49) based ( tr_pt r ) , 
2 x fixed bin ( 15 ) , 

2 y fixed bin (15) , 

2 z fixed bin (15) , */ 
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DECLARE 



i fixed bin ( 15 ) , 

(k, tq_ub,to_lb) bit (16) , 

1 1 oca l_t rac k , 

2 x fixed bin (15), 

2 y fixed bin (15), 

2 z fixed bin (15); 

/* main */ 

%include 'pointer. ass ' ; 

do i = 0 to infinity; 

/* simulation of track input data */ 
local_track.x=i+i; 
local_track.y=i+10; 
local_track.z=i+l» 

/* put track in shared memory */ 
track( mod ( i , t a len ) ) = local_trackJ 
call advance (TRACK_IN); 
tq_ub = read(TR^CE_IN) J 

/* display track values */ 

put skip(2) edit ('Track ' , binary( ta_ub ) , 

x: ' , local_ t rack . x , 

y: ', local _t rack .y, 
z: ' , local_track . z , 
put in aueue slot ' .mod ( i , ta len ) ) 
(4(a,f (5) ) ) ; 

to_lb = read (TRACK_0UT); 

/* report status */ 

put skip(2) edit('Last consumed track ' , binary( tq_lb ) , 

in slot: ', mod ( binary ( tq_lb ) -1 , to len ) ) 
(2(a,f (5) )) ; 

/* check if slot available for next iteration */ 
if ( ( bi nary ( to _ub )-binary ( to _lb ) ) >= talen ) then 
do; 

k = add2bitl6( ta_lb,one); 

/£ reoort status */ 

put skip(2) edit ('Waiting for slot: ', 

mod(binary(k)-l, talen) . 

to be consumed ') (a,f(3),a); 

call await ( TR ACE_0UT , k)J 
end; 

end; /* do FOREVER */ 
end trkdetect; 
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Sjc # 3$C 3JC # # 3JC # # # 5jS 5}C # # 3jC # Ifi. # 3$C # # 3jC 3)C # # # # # 3}C 5jC # 3{C 5jC # 5jC jJC # 3jC # »JC 3$C 5jC 3* # # 3$C 5$C 3)C 3* J}C 3jC 3jC 3{C # # 3£ 5£ # 3}C 3jC 



*** MSLTRAIN . PL I file R. Haeger, Dec 1985 *** 

— — — V#X' 



*** This is the PL/I-86 code for user process msltrain. *** 
*** it simulates missile launcher training by - *** 

*** displaying launcher assignment and direction values. *** 
*** It consumes shared data MI SSI LE_ORDER . *** 

JU sU JU Ju ^ %u %«<* J/ J# ^ %•/ ^ < hV vV ^ *jV y# JU ».v J# «/# %*# V" %V V# •/# %V •>*# ^*4 %*4 y# %v ^ *J* 

*yt >|*i ^ /p #p >p >p ^p #p ^p >|«. #p ^p /p #p >p >p >p >p #p #p ^p >p >p ^p ^p >p >p 4p #p rp #g% 4p rp fp #p 4p >p #p /p >p ^|% /p #p #p /|% 



# # # 5}; 3}C # Sjt # # # 3* 5jc 3£ 3*,C # 3}S # # 3{C # >£ 3jC 3jC # # # # # 3{C # 3fc # # 3fc # 5}; 3jC # # 5jC 3jC # # 3* 3jC 3jC # # 3jC 3jC # 3£ # # s£ 3* 3}C # 3{C 3£ 



msltrain: procedure ; 

%replace 

infinity by 32767, 

one by '0001 'b4 , 

moqlen by 50? 

%include 'sysdef .nli ' ; 

%include 'share. del'; 

/* used shared data: 

1 miss ile_order ( 0: 49 ) based (mo_ptr ) , 

2 launcher fixed bin (7), 

2 azimuth float binary, 

2 elevation float binary, */ 

DECLARE 

i fixed bin ( 15 ) , 

k bit (16) static init ('0000'b4); 

/* end DECLARATIONS */ 

/* main */ 

^include 'pointer . ass ' ; 

do i = 0 to infinity; 
k = add2bitl6(k, one); 

/# report status */ 
put skip list ( 'msl train waiting'); 
call await ( MISS ILE_ORDER_I N , k); 

/* consume and disulay missile order values */ 
put skip(2) edit ( 'launcher: ', 

missile_order*mod( i,moalen) ) .launcher , 
launch: ',binary(k), 
azimuth: ', 

missile _order(mod(i , moqlen) ) .azimuth, 
elevation: ', 

missile or de r ( mo d(i, moqlen)). elevation) 
( 2 ( a , f T 5 ) ),2(a,e(10,2)) ); 
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call al vance ( MI SS I LE_ORDER_OUT ) ; 
end; /* do i */ 
end msltrain; 









*** C2USERS . I NP file *** 

«>:<# -f -f * 



*** This file is used to link user initialization, 

user process mslorder, user process trkrort, and *** 
*** gatemodule into C2USERS.CMD, the executable file *** 
*** rnul t iplex in£ the two user processes on one SBC. *** 



c2users = 

c2uinit [code [ab [43911 ,data[ab[800l , m [0) ,ad[82ll ,rnap[all]l , 

mslorder , 

trkrprt, 

<?atemod 



*** C2UINIT.PLI file *** 

3^3^$ — — — — - — — — — ■ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —— —— —— — —— — —— — — — Jr tv 

*** This is the initialization procedure for the 

*** multiplexed user constellation. *** 



mr 3{C #jc 5j6 >}j 3jS SjS 3jS 3$C 3{C 3jS jj 






c2_users_i nit : procedure options (main); 

^include 'sysdef .pli ' ; 



/'" begin */ 



/* missile order */ 
call create_t>roc ('03'b4, 'fc'D4 t 

'0a29'b4, '0800 'b4 , '0029'b4, 

'0439 'b4 , '0800 'b4, '0833 'b4)5 



/* track report */ 
call create_oroc ('04'b4, 'fc'b4. 

'0b47'b4, '0803 ' b4 , '0333'b4, 

'0439 'b4, '0800 'b4, '0300 'b4 ) 5 
call await ('fe'b4, '01'b4); 
end c2 users init; 



3£#3}C#3}C;f;3£## J^JJCSjC # Sis#### SjC^C ###:£#:{< V 
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REPORTER. IMP file 



###_ — — — — * _ 

*** This file is used to link trkrprt initialization, 
*** user process trkrprt, and gatemodule into . 

*** REPORTER.CMD, the executable file for user process 
*** trkrprt in the non-multiplexed constellation 



- 5 jS 5 {t ?{C 
### 

*r ^ ?!' 

*.•- y# »)« 
mr* v v 



S.U J» Jf sV «V V> U« J* *A» »t* ■>*< *•# sV U* »•» J, sJU *t* »<» <A> %l< J< »<» J* sJL# >1# «V s'# si# s'# s'# si# J# si# s'# si# si# si# s># «J# J# si# si# si# si* si# si# si# si# si# s J+ si# si* s'* s'* s'* s'* si* s'* 

#(S #|S # ( S y #jl* l^s # 4 » #|S #jS*.s *J-S # ( s <#|% # 4 v #|S *ys #|S #|S # ( s rjs #|S ^s #js #|S rjS #|S #|S #ys #(S ^|S #,s^S #*]S ^s ^ #js #qS* #|-s #js >|S *,s #|S * ( s #^s #|S #js qs *|S qs qs # ( s *js *|S qs qs > ( s # ( s qs * t s 



repo rter= 

trkrini t [c ode [ab [439] ] ,data [ab [B00],m[0] ,ad [82] ] , mao[all]] , 

trkrprt , 

gatemod 



##*- 



’PKRIMIT.PLI file 



This is 
process 



*#:{e 

the initialization procedure for user *** 

trkrprt in the non-multiplexed constellation.*** 



%•* *£+ *V V* V* sU i 1 # sV %V ^ sV ^ %U U# >*# U# J# sV «V ^ J/ %V %o %'# %i# «i# J# %'# %»# %V ^ 

* 4 * V '4* #p ^ ^ 4 ^ #(> ^P Zp *|*k ^p ^P ^1% #P ^P #p #^p #p /p rp «*p #P #P ^P rf* rp i^p #p ^|S /p rp ^ #p /p rp ^p <p /p /p /p 



trkrinit: procedure options (main); 

%include 'sysdef .pli ' ; 

/* begin */ 

call create_oroc ('04'b4, 'fc'b4, 

'037f'b4, '0P00'b4, '0023'b4, 

' 0439 'b4 . '08^e'b4, '?800'b4); 



call await ('fe'b4, '01'b4); 

end trkrinit* 



## 5 ^C 2 ^ 5 jc 5 ^ 5*5 # # # S£ # 5 JC # # # # # # # # J$C # # # # # 

s£ # # # # # sjc # # s[c # 5 [r # ;Jc s(c # $ i\i # # :fc s£ sjs s*< 5;? s{c # # £ £ # # sjs sjt # # sjc # sjc s[c sjc a*c # # # j£ ajc 5^ # # >Jc # # # # # 



*** MS LORD. IN? file *** 

### 



*** This file is used to link mslorder initialization. *** 
*** user process mslorder, and gatemodule into *** 
*** MSLORD.CMD, the executable file for user process *** 
*** mslorder in the non-mul t iplexed constellation. *** 



mslord = 

msloinit [code [a b [439] ] ,data [ab [800] ,m [0] ,ad [82] ] , mao [all] ] , 
mslorder , 
gat emod 

# # # # S$C # # # l|C 2jS # # >JC # # # # # * # # # # Jjc # # 5$C # 5jC 5J: # 5^ ifiC 3^ 5^ # 5^ # 5}C 5^ >}C 5^ # ^ # 5jt 5^ 5^ Jj: # 5^ ^ 3^ 
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*******if******ififififif*ififififififififififififif^fifififififififififififififififififififif7fififififif 
********************** *##*##*##*##* ifif* % *i<ifififififififififiifif*ifififififififif 



*** MSLOIN IT . PLI file *** 

*** — *** 



*** This file is the i r.tializat ion orocedure for user *** 
*** process Tislorder in the non-mul ti plexed constellation*** 



msloinit: procedure ootions (main); 

%include 'sysdef .pli ' ; 



/* begin */ 

call create_oroc ('03'b4, 'fc'b4, 

'09b3'b4, '0800 'b4, '0023 'b4, 

'0439 'b4 , '0800 'b4 , '0800'b4)J 

call await ('fe'b4, '01'b4)» 
end msloinit; 



TRKRPRT.PLI file 



R. Haeger, Dec 1985 



* * * * if ## if if if if if if # #>;s5£;;;s:£ ####:£ >jc ### ifc# # if if ^ if if if if if if * if if if sjc it if if if if if #>Jc if if ## if if if 
#####>£ if yf if # if it if if if if it if if if if if yf >;< Xf if # if if if if if if if if if # if if if if if if if if if if :£ if if if if if :jc if 

*** 

X** 

*** 

*** 
s'/ V»* 

*r +(* »%■* 

Jr## 

V# 

*1* 



This is the PL/I-86 code for user process trkrprt. 

It simulates computation of delta values for tracks 
by comparing two consecutive positions of a track. 

It consumes shared data TRACK and produces shared 
data DELTA. 

if # if * * * if if if if * * * * if if * if if if * if * if if * if j;< * sjc * if if if * * if # if * if if if if if if if if if if if if 



— 5r 't 

* n* * 

* n* *i* 
n'»iS»r 

V * * 

%U .V J# 
^ 



trkrprt: procedure ; 

^replace 



infinity 


by 


32767, 


one 


by 


' 0001 ' b4 , 


da len 


by 


20 , 


ta len 


by 


50 ; 



^include 'sysdef .pli '; 

^include 'share. del'; 

/* used shared data: 

1 track(0:49) based ( t r_pt r ) , 
2 i fixed bin ( 15 ) , 

2 y fixed bin (15) , 

2 z fixed bin (15) , 
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1 delta(0:19) based ( de_ptr ) , 

2 dx fixed bin (7 ) , 

2 dy fixed bin (?) , 

2 d 2 fixed bin (7 ) , */ 

DECLARE 

i fixed bin (15), 

(km,k) bit (16) static init ('0000'b4), 

(iq_ub ,dq_lb ) bit (16), 

1 local_track, 

2 x fixed bin ( 15 ) , 

2 y fixed bin ( 15 ) , 

'waiting for slot ', 
mod(binary(k)-l ,dqlen) , 

to be con 2 dy fixed bin (7), 

2 dz fixed bin (7); 

/* end DECLARATIONS */ 

/* main */ 

^include ' pointer. ass 

do i = 0 to infinity; 

/* report status */ 

put skip(2) list ( 'proc trkrprt, iteration: ', 

i , ' waiting ' ) ; 

km = add2bitlo(km , one); 
call await (TRACK_IN, km); 

/* renort status */ 
put 1 ist ( ' going ' ) » 

/* read shared data item and compute delta values */ 

local _delta.dx=( track(mod(i, tqlen) ) .x)-(local_track.x) ; 

1 ocal_del ta .dy= ( tra ck ( mod (i,talen)).y)-(local_track.y)> 

1 ocal_delt a ,dz= ( track (mod (i,talen)).z)-(local_track.z); 

/* display computed delta values */ 
put skip list( ' ix : ' , local_del ta .dx , 

dy: ', local _del ta . dy , 
dz : ' ,local_delta .dz ) ; 

/* save track data for next iteration */ 
local _track=track(mod(i,tolen)); 

/* put delta in shared memory */ 
delta(mod(i,dolen))=local_delta; 
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call advance ( DELTA_I N ) ; 

/* report status */ 
out list ( ' done ' ) ; 

dq_ub=read (DELTA_IN )? 
dq _lb=read ( DELTA _0UT ) ; 

/* check: if slot available for next iteration */ 
if ( (binary(do_ub )-bi nary (dq _lb ) ) >= dqlen) then 
do ; 

k=add2bi tl6(do_lb,one); 

/* if queue is full, report status */ 
put skip(2) edit('Delta queue full, 

'waiting for slot ', 
mod(binary(k)-l,dolen) , 
to be consumed') 

(a ,a , f (3 ) , a ) ; 

call await ( DELT A_OUT , k ) ; 

end ; 

end; /* do i #/ 
end trkrort; 



s}c # 5^ # # # # sjc # # # s;: # # # # ije # # # # # # # 3 Jc # # # # # # # sjc # sjs # # sjc # # # # # ;Jc # sjs 



#####*###*### ##*### 3* v*# 3* ajssjcajc 









MSLOEDER . PLI file 



R. Haeger, Dec 1965 



C # # 3* # *S 






-v V' 



*** This is the PL/I-36 code for user process mslorder. *** 
it simulates computation of missile launcher *** 

*** direction and launcher assignment. *** 



*** It consumes shared data TRACK and DELTA, and 
*** produces shared data MISSILE ORDER. 






s(s :Jt 



WV'IC' 



mslorder: procedure ** 

^replace 



infinity 


by 


32767, 


one 


by 


'0001 'b4 


to len 


by 


50 , 


do len 


by 


20, 


moo 1 en 


by 


50 ; 



^include ' sysdef . pi i ' ; 
^include 'share. del'; 
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/* used shared data: 

1 track(0:49) based ( tr_ptr ) , 

2 x fixed bin ( 15) , 

2 y fixed bin ( 15) , 

2 z fixed bin ( 15) , 

1 delta(0:19) based ( de_pt r ) , 

2 dx fixed bin (7 ) , 

'2 dy fixed bin ( 7) , 

2 dz fixed bin (7 ) , 

1 missile_o rder (0 :49 ) based (mo_ptr ) , 
2 launcher fixed bin (7), 

2 azimuth float binary, 

2 elevation float binary, */ 

DECLARE 

i fixed bin ( 15) , 

km bit (16) static init ('0000'b4), 

kd bit (16) static init ('0000'b4), 

(moa_ub ,moa _lb ) bit (16), 

1 local_track, 

2 x fixed bin (15) , 

2 y fixed bin (15) , 

2 z fixed bin (15) , 

1 local_del ta , 

2 dx fixed bin (7) , 

2 dy fixed bin ( 7 ) , 

2 dz fixed bin (7) , 

1 local_order, 

2 launcher fixed bin (7), 

2 azimuth float binary, 

2 elevation float binary? 

/* end DECLARATIONS */ 

/* main */ 

^include 'pointer .ass ' ; 
do i = 0 to infinity? 

/* report status V 

put skip(2) list('proc mslorder, iteration: ', 

i , ' m_wai tin^ ' ) ? 

kd=add2bi tl6(kd , one) ? 
call await ( DELTA_IN ,kd ) ? 
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/* report status #/ 
put list(' m_ffoin 2 '); 

/* copy track values #/ 
local_track = track(mod(i , tq len ) ) » 
call advance(TP.ACK_OUT ) i 
/* copy delta values */ 
local_delta=delta(mod(i f da 1 en ) ) » 
call advance(DELT.A_OUT ) ; 

/* display track values */ 

put skip list(' x : ' , loca l_t rack .x , ' y : ' ,local_track .y , 

z : ',local_track .z ) i 
/* assign launcher */ 
local _order . launcher =mod (i ,4)+l*» 

/* simulate direction commutation */ 
local _order.azi mu th= 

a tand ( float ( local_t rack . y + localdelta .uy ) / 
f loat(local_track.x + local_del ta .dx ) ) ; 
local_order .elevation= 

atand( float( local_track. z + local_delta .dz ) / 
f loa t ( local_t rack .x + local_del ta .dx ) ) ; 
/* put missile order in shared memory */ 
missile_order(mod(i,moqlen))=local_order; 

/* display missile order values */ 
put skip 1 is t ( 1 local _order . launcher , 

a: ' . loca l_o rder . azimuth, 
e: ' , local_o rder .eleva ti on ) ; 
call advance(MISSILE_ORDER_IN ) ; 

/* report status */ 
put li s t ( ' m_done ' ) » 

moo_uh = read ( MI SSI LE_0RDER_I N ) ; 
moq_lb = read ( MISS ILE_CRDER_OUT ) » 

/* check if slot available for next ireration */ 
if ( (bina ry (moq_ub )-binary ( moq _lb ) )>=moalen ) then 
do ; 

km = add2b i tl6 ( moa _lb , one ) ; 

/* report if queue is full */ 
put skip(2) edit ( 'Missile_order queue full, '. 

'waiting: for slot 
mod(binary(km)-l,moolen) , 
to be consumed') 

(a ,a , f (3) ,a ) J 

call await (MISSILE_ORDER_OUT , km); 

end ; 

end; /* do i */ 
end mslorder; 
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APPENDIX F 



SYSTEM INITIALIZATION 

To switch on and initialize the system, follow these 
steps : 

( 1 ) 

Switch on and set up the hardware components of both 
clusters in accordance with the respective power on 
procedures described in the AEGIS lab up to the point where 
the system disks are in their drives and the reset button of 
the MULTIBUS frame was pushed. 

( 2 ) 

Insert MCORTEX disks for cluster 1 and cluster 2 in 
their respective drives. 



(3) 

For cluster 1: 

At terminal 1 type in: capital 'U' . 

After prompt type in: ' gffd4:4' followed by RETURN. 

After prompt choose console ’ 1* and login disk ' B'. 
After prompt B> change to disk A. 

After prompt A> type in: 'ldcpm'. 

After prompt A> type in: ' ldboot ' . 

After prompt A> change to disk B. 

After prompt B> terminal 1 is ready for MCORTEX. 

At terminal 2 type in: capital 'U* . 

After prompt type in: 'ge000:400'. 

After prompt choose console '2' and login disk 'C'. 
After prompt C> change to disk B. 

After prompt B> terminal 2 is ready for MCORTEX. 

At terminal 3 type in: capital ' U' . 
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After prompt type in: ’ge000:400'. 

After prompt choose console *3' and login disk 'D'. 

After prompt D> change to disk B. 

After prompt B> terminal 3 is ready for MCORTEX . 

For cluster 2: 

At terminal 1 type in: capital 'U' . 

After prompt type in: 'gffd4:0'. 

After prompt do the same as in cluster 1 after this 
step . 

Make sure cluster 1 is connected to the RTC* Ethernet. 
System is ready for MCORTEX. 

At cluster 1: 

At terminal 1 type in: 'MCORTEX' followed by RETURN. 

System will ask for global memory to be loaded, type in: 
'Y' and hit RETURN. 

System will ask for filename. 

At terminal 2 type in: 'MCORTEX' followed by RETURN. 

System will ask for global memory to be loaded, hit 
RETURN . 

System will ask for filename. 

At terminal 3 do the same as at terminal 2. 

Cluster 1 is ready for initialization. 

At terminal 1 type in: 'C1PR0C.CMD' and hit RETURN. 

The driver will prompt with length of longest queue, and 
signal that cluster 1 is initialized. 

Cluster 1 is ready for the application processes. 

Initialize cluster 2 the same way as cluster 1, but type 
in: 'C2PR0C.CMD' instead of 'C1PR0C.CMD'. 

After driver prompts, the system is ready for 
application processes. 
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Following, the initialization of the demonstration 
program's non-multiplexed constellation is described. 



(5) 

At cluster 2: 

At terminal 2 type in: 'MSLORD.CMD'. 

User process MSLORDER will start executing. 

At terminal 3 type in: 'REPORTER.CMD'. 

User process TRKRPRT will start executing. 

At cluster 1: 

At terminal 3 type in: 'MSLREACT.CMD'. 

User process MSLTRAIN will start executing. 

At terminal 2 type in: 'TRACKER.CMD'. 

User process TRKDETEC will start executing. 
The total system will run. 



( 6 ) 

Every terminal displays respective data on its screen. 
Terminals 1 in both clusters show message exchange 
activity 'transmitting' or 'receiving'. 

(7) 

To stop any process, hit 'Control S' at the respective 
terminal. To restart the process hit 'Control S' again. 
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